Banking Law and Open Banking Intellectual Property Issues in Spain

1. Introduction

Open banking has changed the traditional relationship between banks, customers and financial-technology companies in Spain. Historically, banks controlled their own software systems, customer interfaces, databases and technological infrastructure. Open banking requires banks, in defined circumstances and with the customer's authorization, to permit regulated third-party providers to access payment-account information or initiate payments.

This creates an important intellectual-property question: how can a bank retain intellectual-property rights over its software, databases, APIs, documentation and branding while simultaneously being legally required to provide technological access to third parties?

Spanish law answers this through a combination of banking regulation, copyright, database rights, trade-secret protection, trademark law, contract law and EU rules on interoperability.

The central principle is that open banking does not normally transfer ownership of a bank's intellectual property to fintech companies. Instead, banking regulation may require the bank to provide functional access to specified data and payment infrastructure. The underlying software, source code, database structure, documentation and branding can remain protected.

2. Legal Framework in Spain

Spain's intellectual-property treatment of open banking cannot be understood from banking legislation alone.

Important sources include:

Royal Decree-Law 19/2018 on payment services and other urgent financial measures;

PSD2, Directive (EU) 2015/2366;

Spanish Intellectual Property Law, consolidated through Royal Legislative Decree 1/1996;

Directive 2009/24/EC on the legal protection of computer programs;

Directive 96/9/EC on the legal protection of databases;

Spanish Law 1/2019 on Trade Secrets;

Spanish trademark legislation;

GDPR and Spanish data-protection legislation;

contractual rules governing API and technology services.

PSD2 created the regulatory foundation under which authorized payment-initiation service providers and account-information service providers can interact with banks' payment-account infrastructure.

Consequently, intellectual-property rights cannot normally be invoked simply to defeat a regulatory access obligation imposed by payment-services legislation.

3. Intellectual Property in Banking APIs

An API—Application Programming Interface—is one of the central technological components of open banking.

Banks may invest substantially in developing:

API software;

authentication systems;

API gateways;

cybersecurity architecture;

developer portals;

technical documentation;

data structures;

payment-processing systems;

fraud-detection technology.

Different components can receive different forms of legal protection.

For example, the actual source code implementing an API can qualify for copyright protection as a computer program. However, this does not automatically mean that the abstract functionality performed by that API is protected.

This distinction is extremely important for open banking.

A bank might own copyright in the specific computer code that operates an account-information interface. That does not necessarily give the bank a copyright monopoly over the general idea of allowing a third-party application to request an account balance.

4. Copyright Protection of Software

Spanish copyright legislation protects computer programs where the relevant originality requirements are satisfied.

Protection can potentially extend to:

source code;

object code;

original software architecture expressed through code;

certain preparatory design materials;

original documentation.

Copyright generally protects expression rather than underlying ideas, principles or functionality.

Therefore, if Bank A develops software enabling third-party providers to request account information, another developer cannot simply copy Bank A's protected source code.

However, copyright law does not necessarily prevent another company from independently creating software performing equivalent functions.

This distinction supports technological interoperability.

Relevance to Open Banking

Suppose a Spanish bank develops an API through which authorized fintech companies can request transaction information.

The bank could retain copyright over its particular software implementation.

A fintech company receiving API access does not thereby acquire:

ownership of the source code;

a right to reproduce the bank's entire software;

ownership of the bank's platform;

unrestricted commercialization rights.

Its rights depend upon payment-services regulation and any valid contractual arrangements governing the technical relationship.

5. API Functionality and Interoperability

One of the most significant intellectual-property issues concerns the distinction between API implementation and API functionality.

A software interface must frequently be understood by another computer system for interoperability to work.

If copyright gave the first developer complete control over functionality itself, interoperability could become extremely difficult.

EU software copyright jurisprudence therefore draws a distinction between protected program expression and unprotected functionality, programming languages and certain data-file formats.

For Spanish open banking this means that intellectual-property law generally cannot be treated as giving banks unlimited control over the concept of interoperating with their systems.

Regulatory requirements reinforce this principle because authorized third-party payment providers need workable technological communication with account-servicing institutions.

6. Database Rights

Open banking also raises important database-right questions.

Banks maintain extensive electronic collections containing information such as:

transaction histories;

payment records;

account information;

merchant information;

customer-related records;

financial-product information.

Under EU and Spanish law, databases can potentially receive two different types of protection.

Copyright protection

A database may receive copyright protection where the selection or arrangement of its contents represents the author's own intellectual creation.

Sui Generis Database Right

Separate protection may arise where substantial investment has been made in obtaining, verifying or presenting database contents.

These rights are conceptually different.

A crucial limitation is that database rights do not necessarily give a bank ownership of every individual fact contained within a database.

For example, the existence of a payment of €50 on a particular date is fundamentally different from copyright ownership in the structure or arrangement of the database storing that information.

7. Customer Data Is Not Simply Bank Intellectual Property

A common misconception is that because a bank stores customer information, all customer information automatically becomes the bank's intellectual property.

That proposition is too broad.

Several legal interests can coexist.

The bank might possess intellectual-property rights in its software or database structure. At the same time, information concerning an identifiable customer can constitute personal data governed by GDPR.

Consequently:

Database ownership ≠ ownership of the customer's personal information in an unrestricted proprietary sense.

Open banking particularly demonstrates this distinction.

The regulatory system can require access to certain payment-account information following valid customer authorization even though the bank continues to own copyright in the software used to store and process that information.

8. Sui Generis Database Rights and Open Banking

The database right can potentially prevent unauthorized extraction or reutilization of substantial database contents.

However, whether particular banking information qualifies for protection requires careful analysis.

An important distinction exists between:

resources spent creating data, and

resources spent obtaining, verifying or presenting existing data.

EU case law has held that investment in creating the underlying information is not automatically treated as investment in obtaining database contents for purposes of the sui generis right.

This distinction could matter significantly in banking systems because banks both generate and collect enormous quantities of information.

9. Trade Secrets

Not every commercially valuable banking technology is best protected through copyright.

Spanish Law 1/2019 on Trade Secrets can protect confidential technical and commercial information where the statutory conditions are satisfied.

Potential banking trade secrets include:

fraud-detection methodologies;

internal cybersecurity procedures;

proprietary risk algorithms;

confidential API architecture;

authentication techniques;

internal technical documentation;

security configurations;

non-public scoring methodologies.

Open banking does not mean that third-party providers receive unrestricted access to all these systems.

A bank may have to provide the interface and information required by payment-services regulation while maintaining confidentiality over unrelated internal technology.

Therefore, an important compliance strategy is to distinguish information necessary for interoperability from confidential internal technology.

10. API Documentation

API documentation creates another layer of IP complexity.

Documentation may contain:

descriptions;

diagrams;

examples;

instructions;

technical explanations;

original written material.

Original expressive elements can potentially receive copyright protection.

But copyright protection for documentation does not necessarily mean that every technical idea described in it becomes proprietary.

A fintech developer might legitimately learn how an interface functions without acquiring a right to reproduce protected documentation wholesale.

11. Reverse Engineering and Interoperability

EU software law recognizes limited circumstances in which observation, study, testing or decompilation can be permissible, particularly in connection with interoperability.

These provisions are particularly important for financial technology.

Without interoperability, different software systems cannot efficiently communicate.

Nevertheless, interoperability exceptions are not unlimited licenses to copy proprietary banking technology.

A developer cannot automatically use them as justification for:

copying protected source code;

distributing proprietary code;

misappropriating confidential information;

creating unauthorized copies of protected software.

The permitted activity must remain within the applicable statutory conditions.

12. Contractual Protection

Banks and fintech companies commonly supplement statutory IP rights through contracts.

Relevant provisions can address:

API licensing;

permitted technical uses;

confidentiality;

cybersecurity;

intellectual-property ownership;

software modifications;

documentation;

subcontracting;

termination;

liability;

service levels.

Nevertheless, contractual freedom is not absolute.

A contractual clause cannot simply neutralize mandatory payment-services obligations where EU or Spanish banking legislation requires access.

This creates an important hierarchy:

mandatory banking regulation → applicable statutory IP rules → contractual allocation of remaining rights.

13. Trademark and Branding Issues

Open banking applications frequently display bank names and logos.

This raises trademark issues.

A third-party provider may need to identify the customer's bank so that the customer can select the relevant institution. But necessary identification does not automatically authorize the provider to present itself as officially endorsed by that bank.

Potential disputes include:

unauthorized logo reproduction;

misleading co-branding;

confusing application names;

false suggestions of partnership;

use of bank trademarks in advertising.

Consequently, fintech companies should distinguish legitimate identification of a financial institution from use suggesting commercial affiliation or endorsement.

14. Fintech-Created Intellectual Property

Open banking IP issues are not one-sided.

Fintech companies themselves may create valuable intellectual property, including:

applications;

aggregation software;

analytics engines;

interfaces;

budgeting systems;

payment technology;

proprietary algorithms.

Access to bank data does not automatically transfer ownership of a fintech company's independently developed software to the bank.

Contracts therefore need to distinguish clearly between:

Background IP – technology that a party already owned before entering the relationship.

Foreground IP – technology created during the contractual project.

This distinction becomes particularly important where a Spanish bank commissions a technology provider to build an open-banking platform.

15. Case Law

There is not a large body of Spanish Supreme Court jurisprudence specifically deciding “PSD2 API copyright” disputes. The most important authorities therefore include CJEU decisions interpreting harmonized EU copyright, software and database rules applicable in Spain.

Case 1: SAS Institute Inc. v World Programming Ltd — C-406/10 (2012)

This is one of the most important software-IP judgments for open banking.

SAS developed computer programs, while World Programming created competing software capable of performing similar functions.

The Court distinguished the protected expression of a computer program from its functionality.

It held, in substance, that the functionality of a computer program, programming language and relevant data-file formats were not themselves protected as expressions of the computer program under the software copyright regime.

Importance for Spanish Open Banking

The judgment demonstrates why a Spanish bank cannot necessarily claim copyright ownership over the abstract function performed by an API.

Its source code can be protected.

Its underlying functionality is a different matter.

This distinction facilitates interoperability while continuing to protect actual software expression.

Case 2: UsedSoft GmbH v Oracle International Corp. — C-128/11 (2012)

This case concerned computer-program licensing and exhaustion of distribution rights.

Oracle supplied software through internet downloads accompanied by licences. The Court considered when the distribution right in software becomes exhausted and the circumstances in which subsequent acquirers can qualify as lawful acquirers.

Importance for Open Banking

Open-banking infrastructure frequently relies on licensed software rather than technology entirely developed internally by banks.

A Spanish institution must therefore identify whether:

software is internally owned;

software is licensed;

third-party libraries are incorporated;

licensing conditions restrict redistribution;

developers possess sufficient rights to modify or integrate components.

Regulatory obligations to provide banking interfaces do not automatically eliminate third-party software copyrights.

Case 3: Football Dataco Ltd and Others v Yahoo! UK Ltd and Others — C-604/10 (2012)

This case clarified the copyright standard applicable to databases.

The Court held that database copyright depends on whether the selection or arrangement of data constitutes an original expression of the author's creative freedom. Significant labour and skill alone are insufficient where originality in selection or arrangement is absent.

Importance for Banking

A bank cannot assume that an enormous database automatically receives copyright protection simply because substantial effort was required to create it.

Protection must be examined separately under:

database copyright; and

the sui generis database right.

This matters when determining what IP rights exist in transaction databases accessed through open-banking interfaces.

Case 4: British Horseracing Board Ltd v William Hill Organization Ltd — C-203/02 (2004)

This landmark judgment concerned the sui generis database right.

The Court distinguished investment used to create underlying data from investment directed toward obtaining, verifying or presenting database contents.

It also examined extraction and reutilization of database contents.

Importance for Spanish Banks

Banks cannot simply argue:

“We spent a great deal of money producing this information, therefore every item is protected by database rights.”

The legal question is more specific.

Courts must determine the nature of the investment and whether the statutory requirements for database protection are actually satisfied.

Case 5: Fixtures Marketing Ltd v OPAP — C-444/02 (2004)

The Court confirmed a broad understanding of what can constitute a database while again distinguishing investment in obtaining existing materials from resources devoted to creating the underlying information.

The Court concluded that resources used to create the materials making up a database are not automatically investment in obtaining database contents for purposes of the sui generis right.

Importance for Open Banking

Banking platforms contain both:

externally obtained information; and

internally generated information.

The distinction can influence the scope of database-right protection.

The case therefore helps determine whether particular collections used in Spanish open banking fall within the special database-right regime.

Case 6: Ryanair Ltd v PR Aviation BV — C-30/14 (2015)

This case examined a database that did not qualify for protection under either copyright or the sui generis database right under Directive 96/9.

The Court held that, for a database falling outside those protections, the Database Directive did not itself prevent contractual restrictions on third-party use, subject to applicable national law.

Importance for Spanish Open Banking

The case demonstrates the importance of contract law where statutory database protection is unavailable.

An open-banking platform may therefore involve several overlapping layers:

statutory IP rights + API terms + banking regulation + contract law.

However, in regulated open banking, contractual restrictions must still operate consistently with mandatory payment-services obligations.

Case 7: CV-Online Latvia v Melons — C-762/19 (2021)

CV-Online operated an online employment database, while Melons operated a specialized search service.

The CJEU examined whether activities of a search service could constitute extraction or reutilization under the sui generis database right and emphasized the relationship between database protection and investment in obtaining, verifying or presenting contents.

Importance for Open Banking

The decision is useful when considering fintech services that aggregate information from multiple sources.

Account-information service providers may aggregate customer-authorized financial information from several banks.

The legal analysis must distinguish between:

regulatory authorization to access payment-account information;

database rights;

customer authorization;

subsequent reutilization of information;

contractual limitations.

16. Regulatory Access Versus IP Ownership

This is the most important conceptual distinction.

Suppose:

Bank A owns its API software.

Fintech B is an authorized account-information service provider.

Customer C authorizes Fintech B to obtain account information from Bank A.

Bank A may continue owning copyright in its API source code.

But ownership of that code does not necessarily permit Bank A to refuse every form of legally required open-banking communication.

Fintech B receives regulated access to specified functionality and information.

It does not automatically receive ownership of Bank A's source code.

Thus:

Access ≠ ownership.

Interoperability ≠ transfer of copyright.

Customer-authorized data access ≠ unrestricted copying of a bank's database.

17. Intellectual Property and Competition

IP rights can also interact with competition law.

Banks legitimately need to protect proprietary technology and cybersecurity systems. At the same time, IP claims should not automatically become mechanisms for frustrating regulatory interoperability.

Open banking was designed partly to allow regulated third parties to provide innovative payment and information services.

Consequently, Spanish institutions must balance:

protection of proprietary technology;

cybersecurity;

customer privacy;

regulatory access;

interoperability;

fair competition.

The existence of IP rights therefore does not automatically resolve an access dispute.

18. Security Information Versus Interoperability Information

Another important distinction concerns cybersecurity.

A bank may need to publish technical information sufficient for third-party providers to interact with its interface.

That does not mean the institution must publicly disclose:

source code;

encryption secrets;

private cryptographic keys;

internal fraud rules;

confidential cybersecurity architecture;

penetration-testing information.

Open banking therefore requires controlled interoperability rather than complete technological transparency.

Trade-secret protection remains especially important in this area.

19. Data Protection and IP Rights

Intellectual-property law must also be separated from data-protection law.

For example, a bank may possess database rights over the structure of a financial database while GDPR governs processing of personal information contained inside it.

The two regimes answer different questions.

IP law asks questions such as:

Who can reproduce the software or extract protected database contents?

Data-protection law asks:

Who may lawfully process personal data, for what purpose, on what legal basis, and subject to what safeguards?

Therefore, obtaining an IP licence does not automatically create GDPR authorization to process personal financial information.

Likewise, GDPR authorization does not automatically grant permission to reproduce protected software.

20. Practical Allocation of Rights

A well-designed Spanish open-banking agreement should therefore identify separately:

21. Main Legal Risks

For Spanish banks, the principal IP risks include unauthorized software copying, leakage of trade secrets, misuse of documentation, infringement of third-party software licences and misuse of bank branding.

For fintech companies, the risks are somewhat different.

They include:

exceeding permitted API access;

unauthorized database extraction;

reproducing protected documentation;

copying source code;

violating contractual restrictions;

misleading trademark use;

improperly using confidential information.

Banks also face the opposite risk: attempting to impose IP restrictions that conflict with mandatory regulatory access requirements.

22. Relationship Between PSD2 and Intellectual Property

PSD2 should not be understood as abolishing intellectual-property rights.

Instead, it creates a regulated access environment.

A bank can therefore simultaneously:

own copyright in its banking software;

possess database or trade-secret rights;

own trademarks connected with its financial services; and

remain legally required to facilitate specified payment or account-information services for authorized providers under applicable regulatory conditions.

This coexistence is one of the defining characteristics of open banking.

23. Future Importance

The issue is becoming more significant as European financial regulation develops beyond traditional payment-account open banking toward broader data-sharing and open-finance structures.

Future systems may involve wider categories of financial information and increasingly sophisticated API ecosystems.

This will increase the importance of clearly separating:

ownership of technology;

ownership or protection of databases;

rights concerning individual data;

regulatory data-access rights;

customer authorization;

API licensing;

trade secrets;

cybersecurity;

interoperability.

24. Conclusion

Spanish open banking creates a careful balance between intellectual-property protection and regulatory interoperability.

Banks do not lose ownership of their software merely because they must provide regulated API access. Copyright can protect original source code and software expression, database law can protect qualifying databases, trademarks can protect banking brands, and trade-secret legislation can protect confidential technology and commercial information.

At the same time, those rights are not unlimited.

EU jurisprudence establishes particularly important boundaries: software functionality is different from protected source-code expression; database copyright requires originality in selection or arrangement; substantial investment does not automatically protect data that was merely created by the database maker; and statutory database protection must be distinguished from contractual restrictions.

The leading authorities include SAS Institute v World Programming (C-406/10), UsedSoft v Oracle (C-128/11), Football Dataco v Yahoo! (C-604/10), British Horseracing Board v William Hill (C-203/02), Fixtures Marketing v OPAP (C-444/02), Ryanair v PR Aviation (C-30/14), and CV-Online Latvia v Melons (C-762/19).

The resulting principle for Spain can be summarized simply:

Open banking requires access to regulated financial functionality and information, not surrender of the bank's intellectual-property portfolio. Conversely, intellectual-property ownership cannot automatically be used to prevent access that mandatory banking legislation requires.

That distinction between ownership, access, interoperability and lawful data use is the foundation of intellectual-property analysis in Spanish open banking.