PSD2 Compliance in Spain and Payment Services

PSD2 is the second Payment Services Directive of the European Union. It regulates the provision of payment services, strengthens the security of electronic transactions and opens the financial ecosystem to third parties through the open banking model.

In practice, PSD2 affects banks, fintech companies, payment institutions, electronic money institutions and any model involved in payment initiation, account access, customer authentication or operational infrastructure linked to the service.

It is not just a technical rulebook: it is a framework of authorization, security, governance and ongoing compliance.

PSD2 directly affects payment institutions, electronic money institutions, banks, payment initiation service providers (PISPs), account information service providers (AISPs) and fintech projects that structure services around payments or account access.

It can also indirectly affect technology providers, processors, aggregators, white-label providers and operational partners, whose contractual and functional model must be analyzed precisely to avoid unintentionally carrying out a reserved activity.

The key is not what you call the product, but what your operations actually do.

An AISP provides account information services: it aggregates or presents financial information from one or more of the user’s accounts. A PISP initiates payments on behalf of the user from their bank account to a merchant or payee.

Both models require an analysis of authorization, security, contracts, data processing, operational controls and the relationship with the institutions that hold the account. A technical integration is not enough.

If your business involves account access or payment initiation, the PSD2 analysis must start at the product design stage.

Strong customer authentication (SCA) requires certain transactions to be authenticated using two or more elements from different categories, with specific rules on security and communication.

In addition to implementing the technical layer, you need to review exemptions, payment flows, incidents, fraud rates, customer experience and evidence of how it works in practice. A purely “product” approach usually falls short.

SCA is not defended with a sales pitch: it is defended with architecture, process and records.

It depends on the service you actually provide. If you execute payments, issue electronic money, initiate payments or access accounts as a regulated third party, you may need a specific authorization or registration.

The most expensive mistake is filing an application without first validating your regulatory classification or, worse, operating in the belief that you are just a technology provider when you are in fact carrying out a reserved activity.

Before investing in development, partners or marketing, you should settle the regulatory perimeter and the authorization strategy.

Under PSD2, outsourcing does not remove responsibility. Outsourcing technology, operational service, onboarding, fraud or payment support requires governance, controls, SLAs, oversight, continuity and robust contractual documentation.

The supervisor looks both at the operational chain and at the institution’s ability to control its critical third parties. When the contract does not reflect operational reality, problems arise.

Poor outsourcing does not make compliance cheaper: it multiplies the cost.

The cost depends on the type of activity, how mature the project is, whether operations are already running and whether we are talking about an assessment, a full authorization or ongoing compliance.

What matters is not to look only at the initial legal cost: a wrong regulatory classification, poorly handled SCA or an inconsistent application ends up costing far more than doing the work properly from the start.

Under PSD2, apparent savings at the outset tend to turn into delays, requests for information and friction just when it hurts most.