EU Open Banking Compliance Checklist: PSD2, Consent, SCA and Third-Party Provider Due Diligence

Important: This checklist is general information for product and compliance teams, not legal advice. Open banking obligations depend on your exact services, money and data flows, contracting entities and the Member States involved. Take advice from qualified counsel on your specific model.

Open banking lets a customer give a third party access to a payment account held elsewhere, either to read account data or to initiate a payment. For product teams the engineering is increasingly packaged. The legal structure underneath is not, and it decides who may offer the feature, who answers to a regulator and who is liable when something goes wrong.

This checklist follows that structure. It complements our briefings on choosing payment partners and on payment orchestration vendors; here the focus is narrower: the legal requirements of EU open banking and how implementation responsibilities divide between banks, licensed providers, merchants and technology vendors.

Open banking legal framework in the EU

The base layer is the revised Payment Services Directive, Directive (EU) 2015/2366 (PSD2). It brought account information and payment initiation services into regulation and required banks to let authorised third parties access online payment accounts. Its technical detail sits in the regulatory technical standards on strong customer authentication and common and secure communication (Delegated Regulation (EU) 2018/389, as amended).

Three further instruments matter in practice: the GDPR for personal data, the Digital Operational Resilience Act (DORA), which has applied since 17 January 2025 to payment institutions, e-money institutions, account information service providers and credit institutions, and EBA guidelines and Q&A on PSD2.

Reform is under way. The Commission proposed a third Payment Services Directive and a directly applicable Payment Services Regulation in 2023, and a separate Financial Data Access framework. As of November 2026 the payments package is still completing the legislative process, and it will apply only after transition periods. For now, build to PSD2 and its RTS, and track the reform as a roadmap item.

PSD2 scope and regulated activities

Annex I of PSD2 lists the regulated payment services. Point 7 is payment initiation; point 8 is account information. A business that performs either as a service needs authorisation or registration unless an exclusion applies.

The exclusion most often cited by technology companies is Article 3(j): services of technical service providers that support payment services without entering into possession of funds. It expressly excludes payment initiation and account information services. A vendor that connects to bank APIs on behalf of a licensed provider can sit in that category; a vendor that itself provides the account information service to the end user generally cannot.

Checklist:

• Describe each feature in functional terms: who reads which account, who sends which payment order, for whom.
• Identify which entity provides each regulated service to the end user.
• Record why any exclusion is relied on, and review it when the product changes.

AISPs, PISPs and account-servicing banks

PSD2 sets distinct duties for each role:

• Account information service providers (AISPs) may act only on the user's explicit consent, access only designated accounts and associated transactions, must not request sensitive payment data and must not use, access or store data for purposes other than the service requested (Article 67).
• Payment initiation service providers (PISPs) must never hold the payer's funds, must protect personalised security credentials, must not store sensitive payment data and must identify themselves to the bank each time a payment is initiated (Article 66).
• Account servicing payment service providers (ASPSPs), usually banks and EMIs, must communicate securely with authorised providers and treat their requests without discrimination other than for objective reasons. Access may not be made dependent on a contract between the bank and the provider (Articles 66(5) and 67(4)).

Merchants and app operators are usually none of these. They are the payee or the service the user is buying, and their obligations come from their contract with the licensed provider, consumer law and the GDPR, unless they cross into providing a regulated service themselves.

Licensing and passporting considerations

A firm providing only account information services can register under Article 33 PSD2 rather than seek full authorisation, but it still needs professional indemnity insurance or a comparable guarantee (Article 5(3)) and remains subject to the security and authentication provisions. A PISP needs authorisation as a payment institution, including indemnity cover for the liabilities set out in Article 5(2).

Authorisation in one Member State can be passported to others under Article 28, through a notification to the home regulator. Passporting is not a formality: host regulators may apply local conduct rules, language and complaints requirements and supervisory expectations. Our fintech licensing team usually starts with a market-by-market map rather than a single filing.

Strong Customer Authentication

Article 97 PSD2 requires strong customer authentication when a payer accesses a payment account online, initiates an electronic payment or carries out a remote action that may imply a risk of fraud. For remote payments the authentication must dynamically link the transaction to a specific amount and payee.

In open banking flows the bank applies SCA, and Article 97(5) entitles AISPs and PISPs to rely on the bank's authentication procedures. The RTS sets out exemptions. Article 10a, added in 2022, provides that SCA must not be applied to AISP access limited to balances and the last 90 days of transactions, but SCA is needed on first access and again when more than 180 days have passed since it was last applied.

Product teams should plan for re-authentication journeys, failures and timeouts, and should not design screens that collect bank credentials outside the bank's own interface.

Customer consent and permission scope

PSD2 consent is specific. The user consents to a service, to the accounts it covers and, for payments, to a given transaction. Article 94(2) states that providers may only access, process and retain personal data necessary for their payment services with the user's explicit consent.

• Show the user who the regulated provider is, what will be accessed and for how long.
• Keep a log of each consent, its scope, its expiry and its withdrawal.
• Make withdrawal as easy as granting access, and stop data flows when it happens.
• Do not reuse account data for marketing, scoring or model training unless that use is part of the service the user agreed to and has a separate lawful basis.

GDPR and personal data processing

The European Data Protection Board's Guidelines 06/2020 on the interplay of PSD2 and the GDPR treat PSD2 explicit consent as a contractual requirement, separate from the lawful basis for processing under the GDPR. The guidelines also address "silent party" data, such as counterparties appearing in a user's transaction history, and special category data that transaction descriptions can reveal.

Decide who is controller and processor at each step, update privacy notices, run a data protection impact assessment where the risk calls for one, and set retention periods that match the service. Our GDPR and data protection practice handles this mapping alongside the PSD2 analysis.

TPP identification and authorization checks

Under Article 34 of the RTS, providers identify themselves to banks with qualified eIDAS certificates for electronic seals or website authentication, carrying their authorisation number and role. For a fintech that relies on a licensed provider, the equivalent diligence is simple and often skipped:

• check the provider's exact legal entity in the national register and the EBA register of payment and electronic money institutions;
• confirm that the permissions cover AIS, PIS or both, and the countries you plan to serve;
• check whether services are passported or provided through agents;
• repeat the check periodically, because permissions and registrations change.

Outsourcing and technology provider responsibilities

Many teams build on aggregation or orchestration platforms that reach multiple banks through one integration. Using open banking technology in a payment product this way can be efficient, but the legal analysis must follow the roles. viaBanking, for example, describes itself as a software and technical service provider and orchestration layer, with regulated account information and payment initiation services performed by licensed partner institutions; it states that it is not itself a licensed AISP or PISP.

That model has consequences:

• a payment institution that outsources operational functions must inform its regulator, must not impair its internal control, and remains fully liable for the outsourced entity (Articles 19(6) and 20 PSD2, read with the EBA outsourcing guidelines);
• the merchant or app needs to know which licensed entity serves its users, and whether a direct contract or terms with that entity are required;
• the technology vendor's contract should cover service levels, security, sub-processing, audit and information rights, incident notification and exit support.

API security and operational resilience

When evaluating an open banking API, separate the technical promise from regulatory responsibilities. The TPP must still identify itself to banks, protect credentials and communicate securely; the bank must keep its dedicated interface available and performing; and the vendor in between must support both without weakening them.

DORA now sets the ICT risk-management, incident-reporting, testing and third-party risk rules for in-scope financial entities, and replaced PSD2 incident reporting for them. Regulated firms need a register of ICT third-party arrangements and contractual provisions set by DORA; technology vendors should expect those requests during onboarding.

• Agree logging, monitoring and incident notification times in writing.
• Test fallback journeys for bank interface downtime.
• Verify encryption, key management and access controls for stored tokens and data.

Cross-border implementation considerations

Do not assume that one EU launch means one rulebook. National transposition, supervisory practice, language and consumer-information rules, complaint handling, and the way banks implement their interfaces differ between Member States. Plan market launches with a country matrix covering permissions, local requirements, bank coverage and data transfer questions outside the EEA. Our page on European jurisdictions shows how we approach that sequencing.

Compliance documentation and due diligence checklist

Before launch, a product team should be able to produce:

1. a flow diagram showing who provides AIS and PIS, who holds funds and who performs SCA;
2. the regulatory analysis of your own role, including any exclusion relied on;
3. register extracts for every licensed provider, by entity and country;
4. contracts allocating responsibilities between bank-facing provider, technology vendor and merchant;
5. consent texts, consent logs and withdrawal handling;
6. GDPR records: roles, lawful bases, notices, DPIA where needed and retention schedule;
7. security and resilience evidence, including DORA-related information requests;
8. incident, complaint and liability handling for failed or unauthorised payments;
9. a review calendar for licences, contracts and the coming PSD3 / PSR changes.

For a broader overview of the directive itself, see our guide to PSD2 compliance requirements.

Responsibilities should match the architecture

Open banking compliance is mostly a question of allocation. The bank authenticates and grants access; the licensed provider holds the regulated relationship and the consent; the merchant or app owns its customer journey and data use; the technology vendor supports them without blurring who does what. When the contracts, user interface and regulatory analysis all describe the same arrangement, the product is ready to scale across EU markets.