Banking Law and API-Based Open Banking Regulation in Spain

1. What is Open Banking?

Open Banking is the regulated sharing of a customer's banking/payment-account information with authorised third-party providers (TPPs), normally through secure digital interfaces such as APIs.

The basic model is:

Customer → Third-Party Provider → Bank/API → Customer's account

For example:

• A customer has accounts at Bank A and Bank B.
• The customer uses a financial-management application.
• The application obtains the customer's express authorisation.
• The application connects to the banks through regulated access interfaces.
• It retrieves account and transaction information.
• Alternatively, a payment-initiation provider may initiate a payment from the customer's bank account.

The Banco de España itself describes Open Banking as digital sharing of financial information with third parties under conditions expressly authorised by the customer, with the possibility of withdrawing that authorisation.

The crucial legal point is that Open Banking is not simply a contractual API arrangement between two technology companies. Where the API is used for regulated payment-account access, the arrangement sits within a sophisticated regulatory framework involving:

1. EU payment-services law;
2. Spanish banking/payment-services legislation;
3. PSD2 security rules;
4. GDPR/data-protection law;
5. AML/CFT rules;
6. operational-resilience/cybersecurity requirements;
7. consumer protection;
8. banking supervision;
9. potentially competition law.

2. Legal architecture in Spain

The Spanish Open Banking framework should be understood as a multi-layered regulatory system.

The central Spanish statute is Real Decreto-ley 19/2018, de servicios de pago y otras medidas urgentes en materia financiera. Its consolidated text contains specific provisions dealing with account-information services, payment initiation and access to payment accounts.

3. PSD2 — the foundation of Open Banking

The principal European instrument is Directive (EU) 2015/2366, commonly known as PSD2.

PSD2 introduced a fundamental change to the traditional banking model.

Previously:

Bank → Customer

PSD2 facilitates:

Bank → Customer + authorised Third-Party Provider

Two services are particularly important.

A. Account Information Service — AIS

An Account Information Service Provider (AISP) can consolidate information from one or more payment accounts.

Example:

Bank A + Bank B + Bank C → AISP → consolidated financial dashboard.

PSD2 defines account-information service as an online service providing consolidated information concerning one or more payment accounts held by the user with one or more payment-service providers.

B. Payment Initiation Service — PIS

A Payment Initiation Service Provider (PISP) can initiate a payment from the customer's account held at another bank.

Example:

Customer → PISP → Bank → €1,000 transfer to merchant.

The PISP does not ordinarily take custody of the customer's funds merely because it initiates the payment.

PSD2 expressly requires a PISP not to hold the payer's funds in connection with payment initiation.

4. Spain's principal legislation: Royal Decree-Law 19/2018

Spain implemented PSD2 principally through Real Decreto-ley 19/2018.

This is the most important Spanish statute for API-based Open Banking.

It contains, among other things:

• Article 5 — reservation of regulated activities;
• Article 7 — account-information service;
• Article 8 — access to payment systems;
• Article 9 — access to accounts held with credit institutions;
• Articles concerning payment institutions;
• Article 15 — account-information service providers;
• Article 16 — professional liability insurance/guarantee;
• Article 36 — consent;
• Article 37 — confirmation of funds;
• Article 38 — access for payment initiation;
• Article 39 — access to payment-account information;
• Articles 40–43 — security credentials and unauthorised transactions.

The structure is therefore important: API access is not an independent right of every technology company. It is a regulated access right associated with regulated payment services.

5. The right of access to account information

One of the most important Spanish provisions is Article 7 RDL 19/2018.

It establishes that payment-service users have the right to use services enabling access to account information, provided the relevant payment account is accessible online.

Importantly, provision of account-information services does not depend upon a contractual relationship between the AISP and the bank maintaining the account.

This has a major commercial consequence.

Traditional model

Bank could say:

"We don't have a contract with this fintech, therefore it cannot access our customer's account."

PSD2 model

That argument is generally insufficient where the fintech is a properly authorised/registered AISP and the statutory requirements are satisfied.

The legislation deliberately separates:

Customer's consent

from

A contractual relationship between AISP and bank.

6. API access: what exactly is legally required?

A critical misconception is:

"PSD2 requires every Spanish bank to provide one particular API."

That is not quite correct.

PSD2 and the RTS establish functional and security requirements, rather than prescribing one single technological API specification.

The Banco de España has specifically explained the distinction between the European PSD2 approach and the more standardised UK Open Banking model. Under PSD2, account-servicing payment service providers determine the access interface, subject to regulatory conditions; the RTS establishes the access conditions but does not prescribe one single API standard.

7. The Regulatory Technical Standards — Regulation 2018/389

The technical heart of European API Open Banking is Commission Delegated Regulation (EU) 2018/389.

Its title is itself revealing:

Regulatory technical standards for strong customer authentication and common and secure open standards of communication.

It applies to:

• Account Servicing Payment Service Providers — ASPSPs;
• AISPs;
• PISPs;
• card-based payment-service providers.

8. Bank's API/access-interface obligation

Article 30 of Regulation 2018/389 requires an online account-servicing payment provider to maintain at least one access interface satisfying specified requirements.

The interface must enable:

AISP

to:

• identify itself;
• communicate securely;
• request account information;
• receive information concerning designated payment accounts and associated transactions.

PISP

to:

• identify itself;
• communicate securely;
• initiate a payment order;
• receive information concerning initiation and execution.

Therefore, an API is not merely a technical convenience. Where it constitutes the regulatory access interface, it becomes part of the bank's regulated payment-services infrastructure.

9. API documentation

Banks must document the technical specification of the interface.

The documentation must specify the routines, protocols and tools required for interoperability.

The documentation must be made available without charge to authorised TPPs, and a summary must be publicly available.

The regulation also establishes advance-notification requirements for changes to the interface, subject to exceptions such as emergencies.

This is important from a legal perspective.

A bank cannot simply say:

"We changed our API yesterday and your fintech stopped working."

Regulated interface governance imposes requirements concerning transparency and change management.

10. Security of API communications

API access must be secure.

The RTS requires secure encryption during Internet communication to protect:

• confidentiality;
• integrity;
• authentication information;
• transaction information.

It also requires secure management of communication sessions and safeguards against misrouting or compromise of messages.

Therefore, an Open Banking API must be viewed as a security-critical financial infrastructure, rather than an ordinary commercial API.

11. Strong Customer Authentication — SCA

One of PSD2's most important innovations is Strong Customer Authentication (SCA).

Generally, authentication must involve at least two independent elements from categories such as:

1. Knowledge — something the customer knows;
2. Possession — something the customer possesses;
3. Inherence — something the customer is.

Examples:

• password + mobile device;
• PIN + biometric authentication;
• device + fingerprint.

The RTS requires security measures for SCA and permits certain exemptions based on risk, amount, recurrence and transaction circumstances.

12. Why SCA matters for Open Banking APIs

Consider:

Customer authorises a fintech application to access Bank A.

The API cannot simply expose the customer's banking data because the fintech possesses an API key.

The regulatory model requires:

TPP identification + customer consent + authentication + secure communication + appropriate access control.

The TPP must not simply obtain unlimited access to the customer's online banking credentials.

This is one of the fundamental legal distinctions between legitimate Open Banking and screen scraping.

13. Screen scraping vs regulated API access

Screen scraping

A fintech receives the customer's banking username/password and effectively logs into the bank as the customer.

Problems include:

• credential exposure;
• excessive access;
• security risks;
• inability to distinguish TPP from customer;
• weaker auditability;
• potentially inappropriate processing of data.

API-based Open Banking

The TPP identifies itself to the bank and operates through a regulated interface.

The RTS expressly requires the interface to allow AISPs and PISPs to identify themselves to the account-servicing provider and to rely on the authentication procedures provided by that provider.

This is one reason why PSD2 transformed European banking architecture.

14. Customer consent

Consent is central.

For AIS:

• the customer must authorise access;
• the TPP should only access designated accounts;
• the TPP cannot treat consent as unlimited permission to harvest all banking data.

PSD2 specifically requires an AISP to provide its service only on the basis of the payment-service user's explicit consent and limits access to designated accounts and associated payment transactions.

15. Consent under PSD2 vs consent under GDPR

This is a sophisticated legal issue.

PSD2 consent and GDPR consent are not automatically identical concepts.

PSD2 governs:

permission to use the regulated payment service.

GDPR governs:

the legal basis and conditions for processing personal data.

A fintech therefore needs to analyse both regimes.

For example:

Customer says:

"I authorise Fintech X to access my bank account."

That may satisfy an element of PSD2.

But Fintech X must separately determine:

• what personal data it processes;
• why it processes them;
• whether processing is necessary;
• the appropriate GDPR legal basis;
• how long it retains the data;
• whether it shares data with another party.

16. GDPR and Open Banking

Banking data is frequently personal data.

Therefore GDPR principles become highly significant:

Article 5 principles

Particularly:

• lawfulness, fairness and transparency;
• purpose limitation;
• data minimisation;
• accuracy;
• storage limitation;
• integrity and confidentiality;
• accountability.

The GDPR expressly requires personal data to be adequate, relevant and limited to what is necessary for the purposes for which they are processed.

Spain supplements GDPR through Organic Law 3/2018 on the Protection of Personal Data and Guarantee of Digital Rights.

17. Data minimisation is particularly important

Imagine an AISP provides a service that only requires:

account balance + recent transactions.

It should not automatically collect:

• years of historical transactions;
• unrelated accounts;
• unrelated financial documents;
• unnecessary personal information.

The GDPR principle of data minimisation creates a strong legal argument against over-collection through APIs.

The CJEU has repeatedly emphasised the importance of necessity and data minimisation in interpreting GDPR.

18. Data ownership — an important qualification

It is common to hear:

"The customer owns their banking data."

This is useful as a conceptual explanation, but legally it is more complicated.

GDPR does not generally establish a simple proprietary ownership right in personal data.

Instead, it establishes:

• data-subject rights;
• lawful-processing requirements;
• transparency;
• access;
• rectification;
• erasure in appropriate cases;
• portability;
• restrictions on processing.

Consequently, the better legal formulation is:

The customer exercises legally protected control and rights over personal data, while banks and TPPs may be controllers/processors subject to GDPR obligations.

The Banco de España uses the "customer decides whether to share" model in its consumer-facing explanation, but this should not be confused with a simple property-law concept of ownership.

19. Liability for unauthorised transactions

This is one of the most important areas of Open Banking litigation.

Suppose:

A fraudster obtains credentials → initiates payment → money leaves customer's account.

Who pays?

PSD2/RDL 19/2018 establishes a consumer-protective liability framework.

The bank/payment provider cannot simply argue:

"The correct password was entered, therefore the transaction was authorised."

The legal question is whether the transaction was actually authorised, and whether the customer acted fraudulently or with gross negligence.

20. Spanish case law: Audiencia Provincial de A Coruña, 2026

A particularly important recent Spanish decision was reported by the General Council of the Judiciary on 3 February 2026.

The Provincial Court of A Coruña ordered a bank to reimburse unauthorised transfers from three accounts, involving approximately:

• USD 157,023;
• EUR 67,141;
• USD 55,583,

plus interest.

The court concluded that the bank had not established that the transactions were actually authorised by the customer or that the customer had acted with gross negligence.

Most importantly, the court distinguished:

technical authentication

from

actual authorisation by the customer.

The bank had shown that the customer's credentials and telephone line had been used, but that was insufficient by itself to establish that the customer had authorised the transfers.

Importance for Open Banking

This principle is highly relevant to API-based payments.

An API log may show:

authentication successful.

But legally, that does not necessarily end the inquiry.

The court's reasoning indicates that the financial institution may still need to establish:

• how the authentication occurred;
• whether the customer actually authorised the transaction;
• whether fraud occurred;
• whether gross negligence existed.

The decision was reported as not final, since an appeal to the Spanish Supreme Court remained possible.

21. Another Spanish example: SMS/phishing fraud

Spanish judicial authorities have also reported cases involving fraudulent transactions following deceptive text messages.

In one case, the court concluded that the bank had not demonstrated fraud or gross negligence by the customer and ordered reimbursement. The case illustrates the interaction between payment-services liability and modern cybersecurity risks such as phishing and social engineering.

This is increasingly important for Open Banking because the API itself may be perfectly secure while the customer-authorisation layer is attacked through:

• phishing;
• SIM swapping;
• malware;
• social engineering;
• fake banking applications;
• fraudulent authorisation requests.

22. CJEU case law: C-409/22 — Eurobank Bulgaria

An important Court of Justice judgment is:

UA v Eurobank Bulgaria, Case C-409/22, judgment of 11 July 2024.

The case concerned:

• payment services;
• authentication;
• consent;
• unauthorised transactions;
• liability of the payment-service provider;
• burden of proof.

Although it concerned the earlier Payment Services Directive framework rather than a Spanish API dispute, its principles are highly relevant.

Legal significance

The distinction between:

authentication

and

consent/authorisation

is critical.

In an Open Banking dispute, therefore, the bank cannot necessarily win merely by producing an authentication record.

23. CJEU case: DenizBank — C-287/19

DenizBank AG v Verein für Konsumenteninformation, C-287/19, judgment of 11 November 2020, dealt with:

• PSD2;
• payment instruments;
• contactless/NFC payments;
• information duties;
• authentication;
• low-value payment instruments;
• consumer protection.

The case is important because it illustrates the CJEU's approach to technology-neutral interpretation of payment-services rules.

The lesson for Open Banking is:

New technology does not automatically escape existing payment-services regulation merely because the technical mechanism is different.

24. CJEU case: Beobank — C-351/21

In ZG v Beobank SA, C-351/21, judgment of 16 March 2023, the CJEU considered payment-service-provider obligations concerning information about the payee and unauthorised transactions.

The Court emphasised that the provider has obligations to give the payer information enabling identification of the person who benefited from a payment transaction.

Relevance to APIs

This strengthens an important principle:

Payment data must be sufficiently transparent to allow the user to understand and challenge transactions.

For API systems, this has implications for:

• transaction identifiers;
• payee information;
• audit trails;
• customer-facing records;
• dispute resolution.

25. CJEU case: Veracash — C-665/23

In IL v Veracash SAS, C-665/23, judgment of 1 August 2025, the CJEU addressed the obligation to notify unauthorised transactions and the consequences of delayed notification.

The Court emphasised that, in cases involving loss, theft, misappropriation or unauthorised use of a payment instrument, the user's failure to notify without undue delay can have consequences where the delay involves intent or gross negligence.

This is relevant to Open Banking because APIs create sophisticated transaction records, making:

• notification;
• monitoring;
• alerts;
• incident response;
• customer communication

increasingly important.

26. AML/CFT regulation

Open Banking does not eliminate anti-money-laundering obligations.

Spain's principal statute is Law 10/2010 on the prevention of money laundering and terrorist financing.

The legislation expressly includes payment institutions and account-information-service providers falling within the relevant provisions of RDL 19/2018 among regulated/obliged entities.

Therefore an Open Banking fintech may have obligations involving:

• customer identification;
• beneficial-owner identification;
• customer due diligence;
• transaction monitoring;
• suspicious transaction reporting;
• record keeping;
• internal controls;
• risk assessment.

27. AML creates a tension with Open Banking

Open Banking seeks:

easier data access + competition + innovation.

AML regulation seeks:

identification + monitoring + restrictions on suspicious activity.

Therefore a fintech cannot argue:

"The customer authorised the API access, so we can process everything."

The provider must still comply with mandatory financial-crime controls.

This is a classic example of regulatory layering.

28. DORA and cybersecurity

The regulatory environment has now moved beyond PSD2.

The Digital Operational Resilience Act (DORA), Regulation (EU) 2022/2554, is particularly important for banks and financial entities using APIs, cloud infrastructure and third-party ICT services.

The Banco de España identifies DORA as a major part of the financial-sector ICT regulatory framework.

DORA addresses matters including:

• ICT risk management;
• operational resilience;
• incident management;
• testing;
• ICT third-party risk;
• outsourcing;
• business continuity;
• cybersecurity.

Thus, a bank's Open Banking API must be viewed as part of its ICT-risk architecture.

29. Cloud outsourcing and Open Banking

Consider:

Spanish bank → API → cloud provider → TPP.

The bank cannot simply outsource the API infrastructure and say:

"The cloud company is responsible."

Financial regulation increasingly requires the regulated institution to retain effective oversight of outsourced ICT functions.

Therefore contracts with:

• cloud providers;
• API gateways;
• cybersecurity providers;
• authentication providers;
• data analytics providers

must be examined from both contract law and financial-regulatory law perspectives.

30. Banco de España's supervisory role

The Banco de España is central to Spain's payment-services regulatory architecture.

It deals with:

• authorisation;
• registration;
• supervision;
• payment institutions;
• account-information providers;
• regulatory compliance.

The Banco de España currently maintains a registration procedure for providers of account-information services, and its relevant procedure was updated in July 2026.

Therefore a fintech seeking to operate as an AISP/PISP in Spain cannot simply create an API integration and commence regulated operations.

It must establish that its regulatory status permits the activity.

31. Authorisation vs registration

This distinction matters.

A PISP generally operates as a regulated payment-service provider and is subject to an authorisation regime.

An AISP-only provider has a specialised registration framework under PSD2/RDL 19/2018.

Spain therefore recognises the particular nature of account-information services.

The compliance analysis should always begin with:

What exactly is the fintech doing?

Not:

"Is it a fintech?"

32. Regulatory classification of the business model

A Spanish Open Banking startup should ask:

Question 1

Does it merely provide technical infrastructure?

If yes, it may not itself be providing a regulated payment service.

Question 2

Does it access payment-account information?

Potentially AISP.

Question 3

Does it initiate payments?

Potentially PISP.

Question 4

Does it hold customer funds?

Additional payment/e-money/banking regulation may arise.

Question 5

Does it provide lending?

Credit regulation may apply.

Question 6

Does it provide investment services?

MiFID II/investment regulation may apply.

The same company can therefore trigger several regulatory regimes.

33. API access and competition law

Open Banking also has a competition dimension.

Historically, banks controlled:

customer relationship + account + financial data + payment infrastructure.

PSD2 opens part of that ecosystem to TPPs.

This creates a potential competition issue if a dominant bank:

• deliberately degrades API functionality;
• imposes discriminatory conditions;
• blocks legitimate TPP access;
• provides inferior performance to TPP-originated payments;
• uses technical restrictions without objective justification.

RDL 19/2018 requires access arrangements in certain payment contexts to be objective, non-discriminatory and proportionate. It also establishes access rights concerning accounts held with credit institutions for payment institutions.

34. The principle of non-discrimination

This can be represented as:

Bank's own payment channel

vs.

TPP payment channel

The bank cannot ordinarily discriminate against the TPP merely because the payment was initiated through the TPP.

PSD2 similarly requires the account-servicing provider to treat payment orders transmitted through a PISP without discrimination except for objectively justified reasons.

35. API downtime and liability

Suppose:

Fintech initiates payment at 10:00
Bank API fails
Payment is delayed
Customer loses a commercial opportunity.

Who is liable?

The answer requires analysis of:

1. PSD2/RDL 19/2018;
2. contractual terms;
3. SLA;
4. technical logs;
5. regulatory duties;
6. causation;
7. negligence;
8. operational resilience;
9. applicable limitation/exclusion clauses.

Therefore an Open Banking API agreement should not be treated like an ordinary SaaS contract.

36. API contracts: key clauses

A sophisticated bank–TPP API arrangement should address:

1. Scope of permitted access

Exactly what accounts/data can be accessed?

2. Authentication

What authentication mechanisms are used?

3. Authorisation

How is customer consent recorded?

4. API availability

What uptime is required?

5. Incident management

How quickly must security incidents be reported?

6. Data protection

Who is controller/processor?

7. Data retention

How long can data be retained?

8. Subprocessors

Can the TPP use cloud providers?

9. Security testing

Who performs penetration testing?

10. Audit rights

Can the bank/regulator verify compliance?

11. Liability

Who bears losses arising from:

• unauthorised access;
• fraudulent transactions;
• API malfunction;
• data breach;
• regulatory breach?

12. Termination

What happens when regulatory authorisation is lost?

37. A particularly important legal distinction: data breach vs payment fraud

These are not necessarily the same event.

Scenario A — Data breach

Attacker accesses:

account balance + transaction history.

This primarily raises:

• GDPR;
• cybersecurity;
• DORA;
• incident reporting;
• contractual issues.

Scenario B — Payment fraud

Attacker uses compromised credentials to initiate:

€50,000 payment.

Now payment-services liability becomes central.

Scenario C — Both

Attacker obtains account information and then initiates payment.

Now the incident may simultaneously engage:

GDPR + PSD2/RDL 19/2018 + DORA + AML + criminal law + contract law.

This is why Open Banking compliance cannot be managed by a single legal department.

38. The importance of logs and evidence

API-based banking creates enormous amounts of technical evidence:

• authentication logs;
• API calls;
• timestamps;
• IP information;
• device identifiers;
• transaction IDs;
• consent records;
• access tokens;
• authentication events;
• error logs;
• fraud-monitoring alerts.

These records can become decisive evidence in litigation.

The recent Spanish A Coruña case illustrates why:

technical evidence showing use of credentials is not necessarily equivalent to proof of actual customer authorisation.

Consequently, financial institutions need evidence architecture capable of proving the entire authorisation chain, not merely the successful login.

39. Open Banking and consumer protection

PSD2 is not purely an innovation statute.

Its objectives include:

• security;
• consumer protection;
• competition;
• innovation;
• efficient payment markets.

The Banco de España expressly describes these objectives in its Open Banking materials.

A consumer therefore cannot necessarily waive mandatory PSD2 protections simply through standard-form contractual terms.

40. Spain and the emerging PSD3/PSR framework

An important current-development point is that the EU is moving beyond PSD2.

The EU institutions reached a provisional political agreement on PSD3 and the Payment Services Regulation (PSR) in November 2025, and compromise texts were published in April 2026.

This means Spain's Open Banking framework is entering a transition period.

The future regime is intended to modernise:

• payment services;
• electronic-money services;
• fraud prevention;
• customer authentication;
• Open Banking;
• access interfaces;
• data sharing.

For anyone writing a dissertation or legal paper in 2026, it is therefore important to distinguish:

current PSD2/RDL 19/2018 law

from

the emerging PSD3/PSR framework.

41. Financial Data Access — beyond PSD2 Open Banking

Another important development is the proposed broader Financial Data Access framework.

PSD2 Open Banking is primarily focused on:

payment-account data.

The broader European data-access model could extend regulated customer-authorised access into additional financial-data categories.

That represents a major conceptual shift:

PSD2

Open Banking

↓

Payment accounts

Broader Financial Data Access

Open Finance

↓

Potentially:

• savings;
• investments;
• pensions;
• insurance;
• loans;
• other financial information.

Therefore, the future regulatory debate is moving from:

"Can a fintech access my payment account?"

toward:

"Under what conditions can customers control and share their wider financial data?"

42. Case-law principles — consolidated

The relevant jurisprudence can be reduced to several principles.

The EU cases provide the interpretive framework; the Spanish judgments demonstrate how payment-services liability is being applied domestically.

43. The most important legal issue: who bears the risk?

Open Banking essentially redistributes risk among:

Bank / ASPSP

Responsible for:

• secure account infrastructure;
• authentication;
• API interface;
• payment execution;
• fraud monitoring;
• regulatory compliance.

TPP

Responsible for:

• lawful access;
• customer consent;
• secure processing;
• identification;
• data minimisation;
• appropriate security;
• regulatory compliance.

Customer

Responsible for:

• protecting security credentials;
• complying with security requirements;
• promptly reporting loss/unauthorised transactions;
• not acting fraudulently or with gross negligence.

The precise allocation depends on the statutory provisions applicable to the particular transaction.

44. A hypothetical Spanish Open Banking dispute

Consider:

Customer C has an account with Spanish Bank A.

Fintech F is an authorised AISP/PISP.

C authorises F to access the account.

F connects through Bank A's API.

A fraudster compromises C's mobile device.

A €20,000 payment is initiated.

The bank argues:

"SCA was successfully completed."

The customer argues:

"I never authorised the transaction."

Legal analysis

The court would need to examine:

1. Was F properly authorised?

If not, regulatory issues arise immediately.

2. Was API access compliant with PSD2/RTS?

Was the interface secure?

3. Was SCA performed?

What authentication factors were used?

4. Was the transaction actually authorised?

Authentication evidence is relevant but may not be conclusive.

5. Did the customer act fraudulently or with gross negligence?

This affects liability.

6. Did the bank/TPP comply with fraud-monitoring obligations?

7. Was the customer notified?

8. Was the transaction reported promptly?

9. Who controlled the compromised element?

10. What do the technical logs prove?

This is exactly where the recent Spanish case law becomes important.

45. Regulatory compliance checklist for a Spanish Open Banking fintech

A practical compliance framework would look like this:

Regulatory status

•  Determine whether business is AISP/PISP/other regulated activity.
•  Obtain necessary authorisation/registration.
•  Verify Banco de España requirements.
•  Establish passporting arrangements if operating cross-border.

API

•  Bank provides compliant access interface.
•  TPP identification implemented.
•  Secure communication.
•  Encryption.
•  Session security.
•  Transaction identification.
•  API change management.

Customer

•  Explicit consent.
•  Clear disclosures.
•  Consent revocation.
•  Account designation.
•  No excessive data access.

GDPR

•  Lawful processing.
•  Data minimisation.
•  Purpose limitation.
•  Retention policy.
•  Data-subject rights.
•  DPIA where appropriate.
•  Controller/processor analysis.

Security

•  SCA.
•  Fraud monitoring.
•  Incident response.
•  Encryption.
•  Access controls.
•  Penetration testing.
•  DORA compliance where applicable.

AML

•  KYC.
•  Beneficial-owner identification.
•  Transaction monitoring.
•  Suspicious transaction procedures.

Liability

•  Unauthorised-payment procedures.
•  Customer notification.
•  Evidence preservation.
•  Fraud investigation.
•  Allocation of responsibility between bank and TPP.

46. Overall legal assessment

The Spanish model can be summarised as follows:

Open Banking in Spain is not a free-market right to access bank databases. It is a regulated statutory access regime built around authorised third-party providers, customer consent, secure APIs, strong customer authentication, data-protection principles and regulated allocation of payment risk.

The architecture is:

PSD2
↓
RDL 19/2018 (Spain)
↓
AISP/PISP regulation
↓
API/access-interface requirements under RTS 2018/389
↓
SCA + secure communication
↓
GDPR + Spanish data-protection law
↓
AML/CFT
↓
DORA/cyber resilience
↓
Banco de España supervision
↓
Judicial enforcement

And the most important jurisprudential lesson is:

Successful technical authentication is not necessarily the same thing as proof of genuine customer authorisation.

That principle is particularly significant for API-based payments and is strongly illustrated by both recent Spanish litigation and CJEU payment-services jurisprudence.