PSD2 & Open Banking in the EU (2026): ASPSP, AISP and PISP Explained for Personal Finance Apps

TL;DR

PSD2 is the EU directive (2015/2366) that since 14 September 2019 has obliged every bank in the EEA to expose secure APIs so that licensed third-party providers can — with your explicit consent — read your account data and initiate payments on your behalf. It is supervised by the European Banking Authority (EBA) together with national competent authorities such as BaFin (Germany), ACPR (France), Bank of Italy, Banco de España, DNB (Netherlands) and KNF (Poland). For you as a user it means: free multi-bank aggregation in personal finance apps, mandatory two-factor login (Strong Customer Authentication / SCA) and 3-D Secure 2 on most card payments above 30 EUR.

Educational content, not legal or regulatory advice. PSD2 and PSD3 are evolving; verify current state with your national competent authority.

What changed: pre-PSD2 vs PSD2 vs PSD3

Before PSD2 (pre-2018): banks held a monopoly on your transaction data. The only way to feed a budgeting app was screen-scraping — handing the app your online-banking password and letting it log in as you. This violated most bank terms of service, exposed credentials, and broke whenever the bank changed its login page. Card payments online required only a static CVV and, optionally, a clumsy first-generation 3-D Secure SMS.

Under PSD2 (2018–2026): every "Account Servicing Payment Service Provider" (ASPSP — almost every retail bank in the EEA) must publish a free, documented production API for account information and payment initiation, in parallel with its customer interface. Two new licensed roles are created: AISP (Account Information Service Provider) reading data and PISP (Payment Initiation Service Provider) pushing payments. Screen-scraping is permitted only with a fallback mechanism if the bank's API is unavailable, and only by licensed firms.

Toward PSD3 (proposed 2023, expected to apply from 2026–2027): the European Commission's proposal COM(2023)366 splits PSD2 into a directly applicable Payment Services Regulation (PSR) plus a slimmer directive (PSD3), tightens API performance, allows banks to charge for "premium" enriched APIs, and pairs with the new Financial Data Access (FIDA) regulation that extends open-data principles beyond payment accounts to savings, mortgages, pensions and insurance.

Stakeholders: who is who in the open-banking chain

• ASPSP (Account Servicing Payment Service Provider) — your bank: ING, BNP Paribas, mBank, Santander, Revolut, N26, Monzo, etc. Obliged to expose the API.
• AISP (Account Information Service Provider) — a regulated firm that reads your accounts after you consent. Examples: Tink (Visa), TrueLayer, Yapily, Salt Edge, Finicity (Mastercard), Nordigen / GoCardless Bank Account Data, Klarna Kosma. Many personal finance apps — Freenance among them — operate as AISPs themselves or through such an aggregator.
• PISP (Payment Initiation Service Provider) — a regulated firm that pushes "pay by bank" credit transfers on your behalf. Examples: Trustly, Volt, Token, GoCardless.
• PIISP / CBPII (Card-Based Payment Instrument Issuer) — a third party that issues a card and needs to query an account balance before authorising a transaction. Rarer in personal finance.
• You, the Payment Service User (PSU) — sovereign over your data, you grant 90-day renewable consent.

Legal framework

The directive itself is Directive (EU) 2015/2366 of 25 November 2015, supplemented by the Regulatory Technical Standards (RTS) on SCA and common, secure open standards of communication — Commission Delegated Regulation (EU) 2018/389, applicable from 14 September 2019. Each EEA Member State transposed PSD2 into national law:

• Germany: Zahlungsdiensteaufsichtsgesetz (ZAG), supervised by BaFin
• France: Ordonnance n° 2017-1252, supervised by ACPR (Banque de France)
• Italy: D.lgs. 218/2017, supervised by Bank of Italy
• Spain: Real Decreto-ley 19/2018, supervised by Banco de España
• Netherlands: Wet op het financieel toezicht (Wft) amendment, supervised by DNB
• Poland: Ustawa o usługach płatniczych (PSD2 amendment 2018), supervised by KNF
• Ireland: European Union (Payment Services) Regulations 2018, supervised by the Central Bank of Ireland

The UK transposed PSD2 via the Payment Services Regulations 2017 but, since Brexit, has diverged — its parallel open-banking framework is supervised by the FCA.

API technical standards: not one but four (or five)

PSD2 deliberately did not mandate a single API specification, only common security and functional requirements. Four industry standards emerged:

1. Berlin Group NextGenPSD2 — by far the most widely adopted, in DACH, Benelux, CEE and Nordics. Currently at version 1.3.13 / 1.4 with the openFinance API extension. Used by virtually every Deutsche Bank, Commerzbank, ING, Erste, Raiffeisen, UniCredit subsidiary.
2. STET PSD2 API — French market, used by BNP Paribas, Société Générale, Crédit Agricole, BPCE.
3. PolishAPI — Polish bespoke standard, used by KNF-supervised banks; covers AIS, PIS and CAF endpoints.
4. Open Banking UK (OBIE) Read/Write API — UK-only, technically the most mature; not part of PSD2 strictly but rooted in the CMA9 order.
5. Bank-specific dialects — many large banks add proprietary endpoints on top of Berlin Group for richer data (categorisation, beneficiary enrichment).

This fragmentation is why third-party aggregators exist: a single Tink / TrueLayer / Yapily / Salt Edge integration abstracts hundreds of bank-specific quirks behind one developer-friendly API.

AISP / PISP licensing — what it takes

To become a licensed AISP or PISP in the EU you go through your national competent authority (KNF in Poland, BaFin in Germany, Bank of Italy in Italy). Headline requirements:

• Initial capital: 50,000 EUR for a PIS-only firm; 125,000 EUR for an EMI (Electronic Money Institution) that also issues e-money. Pure AISP requires no minimum capital but does require proof of professional indemnity insurance or comparable guarantee, with cover sized to transaction volumes.
• Professional indemnity insurance — calculated under EBA Guidelines EBA/GL/2017/08 based on risk profile and volume.
• Fit and proper check — for all directors and qualifying shareholders.
• Operational & security framework — incident-reporting plan, business continuity, ICT risk under DORA (Digital Operational Resilience Act, applicable since 17 January 2025).
• Governance — three-line-of-defence model, outsourcing register.
• Timeline: ~6–12 months from a complete application to authorisation.
• EEA passport: once authorised in one Member State, the licence can be "passported" to every other EEA country via notification (typically 1–3 months).

Lighter-touch national exemptions exist for very small AISPs (the "registered" rather than "authorised" regime under Art. 33 PSD2) but they cannot passport.

SCA: Strong Customer Authentication, the user-facing part of PSD2

Whenever you log in to online banking, initiate a payment, or consent to an AISP reading your accounts, the bank must authenticate you with at least two of the following three independent factors:

• Knowledge — something you know: password, PIN, response to a secret question
• Possession — something you have: registered phone with a banking app, hardware token, registered SIM for SMS
• Inherence — something you are: fingerprint, Face ID, voice

Hence the proliferation of bank push-notifications: a tap in the mobile app is the "possession" factor, your biometric is "inherence", and the two together satisfy SCA.

PSD2 RTS recognise several exemptions so SCA is not required on every single action:

• Low-value payments — single transactions up to 30 EUR (with cumulative caps: 100 EUR or 5 consecutive transactions before SCA is forced)
• Recurring transactions — subscriptions of the same amount to the same beneficiary, SCA only on the first
• Trusted beneficiaries — once you "whitelist" a payee with SCA, future payments to that payee can skip it
• Transaction Risk Analysis (TRA) — payment service providers with low fraud rates (e.g. <0.13 % at the 100 EUR band, <0.06 % at 250 EUR, <0.01 % at 500 EUR) may exempt transactions case-by-case
• Corporate payments through secure dedicated protocols
• Account information — SCA required on first connection and at least every 180 days (the "90 days then renew" period was extended by EBA in March 2021)

Liability shift: the user-protective backbone

Under PSD2, if an unauthorised payment occurs from your account, the bank must refund you immediately (typically end of next business day, Art. 73) unless it can prove gross negligence on your part. Your maximum out-of-pocket exposure on unauthorised use of a lost card is capped at 50 EUR. If a PISP initiated the payment, liability sits with the PISP, who then has recourse against the bank if the failure was at the API layer. AISPs that merely read data carry no payment liability but are fully on the hook for GDPR processing under Art. 6(1)(a) (consent) and 6(1)(b) (contract) lawful bases.

PSD3, PSR and FIDA — the 2026+ reform

The Commission's package, proposed in June 2023, contains:

• Payment Services Regulation (PSR) — directly applicable in all Member States, removing the patchy national transpositions of PSD2. Standardises SCA rules, API performance metrics, fraud-liability triggers, IBAN/name matching mandatory on credit transfers.
• Payment Services Directive 3 (PSD3) — focuses on licensing and prudential supervision; merges the EMI regime into a single Payment Institution licence.
• Financial Data Access Regulation (FIDA) — extends open-data principles from payment accounts to mortgages, loans, savings, investments, pensions and insurance, via "Financial Data Sharing Schemes". This is the regulation that makes a holistic financial app realistic at EU scale.
• Non-bank PSP access to payment systems — payment institutions and EMIs get direct access to settlement systems like TARGET2 / TIPS / SEPA Clearing.
• API SLAs — tighter uptime targets (99.5 %+), defined performance, and a ban on obstructive bank behaviour. Banks may offer premium APIs with enriched data for a fee.
• Fraud liability tightening — banks that fail to implement IBAN/name verification or that allow social-engineering scams via spoofed bank caller-ID may bear refund liability.

Adoption is expected in 2026; the regulation typically applies 18 months after entry into force.

PSD2 (EU) vs Open Banking UK (CMA9 + OBIE)

The UK regime is narrower (CMA9 only) but technically tighter and more uniform. The EU regime is broader (~6,000 ASPSPs) but more fragmented.

What this means for consumers

For someone managing money in 2026, the practical PSD2 implications are:

1. Free multi-bank aggregation — you can connect every account you hold across the EEA to one app and see the whole picture; many users benefit from AISP integration to avoid manual CSV imports.
2. Mandatory consent renewal — every 180 days the app must re-trigger SCA in your bank app to keep the connection alive.
3. Login fatigue — your bank app prompts you for SCA on every login above 5 minutes idle and on every payment above 30 EUR.
4. Safer card payments — 3-D Secure 2 with biometric in your bank app instead of SMS codes.
5. Faster refunds on fraud — end-of-next-business-day for unauthorised payments.

For developers and founders building on PSD2

Common pitfalls when wiring an AISP integration:

• Rate limits — banks throttle aggressively; Berlin Group recommends ≤4 calls per consent per day for unattended access.
• 180-day consent expiry — must orchestrate user re-consent flows with reminders; otherwise data disappears overnight.
• API outages — Berlin Group SLAs are advisory, not mandatory under PSD2; PSD3/PSR is expected to tighten this to a measurable 99.5 %.
• MIFID II overlap — if you display investment data, you risk being seen as offering investment advice; structure carefully.
• GDPR Art. 6 lawful basis — PSD2 consent ≠ GDPR consent; document both.
• DORA compliance since January 2025 — ICT risk management, third-party register, incident reporting within 4 hours of detection.

Worked example: a 30-year-old aggregating three accounts

Anna, 30, lives in Warsaw, earns in EUR remote-working, and uses three accounts: mBank PLN current account, Revolut EUR for travel, and N26 DE for German rent. She connects all three to a personal finance aggregator. Here is what flows:

• mBank (PolishAPI) — current and savings balances, last 90 days of transactions, refreshed up to 4×/day. SCA in the mBank app every 180 days.
• Revolut (Berlin Group) — multi-currency wallet balances, transactions, refreshed up to 4×/day. SCA in Revolut app every 180 days.
• N26 (Berlin Group) — current account, transactions, refreshed up to 4×/day. SCA in N26 app every 180 days.

Aggregated, the app calculates Anna's Financial Freedom Runway across currencies, categorises spending, projects cashflow. What is NOT shared: transaction history beyond 90 days (requires fresh consent + bank-side support), security/investment positions outside payment accounts (these are out of PSD2 scope today; FIDA will change that), and any data you have not given explicit consent to share. Freenance, as an EU-native AISP-integrated personal finance and AI cashflow companion, is one of the apps designed around exactly this multi-bank, runway-first view.

Polish reader angle: PolishAPI vs Berlin Group and KNF licensing

Poland chose to develop a bespoke API standard, PolishAPI, maintained by the Polish Banking Association (ZBP). It covers AIS, PIS and CAF endpoints and is mandatory for all KNF-supervised banks. The big four — PKO BP, mBank, ING Bank Śląski, Santander Bank Polska — have mature, well-documented PolishAPI implementations, with Millennium and Pekao close behind. Smaller cooperative banks and BNP Paribas Polska historically lagged by 2–3 years on data completeness, although by 2026 most have caught up.

For a Polish startup wanting to become an AISP, KNF requires:

• A complete application via the eKNF portal
• Proof of professional indemnity insurance scaled to volume
• Detailed operational risk and ICT risk plan (DORA-aligned)
• Fit-and-proper documentation for board members
• Polish-language operational documentation

Approval times have tightened from ~12 months in 2019 to ~6–9 months by 2026 as the regulator's PSD2 team has scaled.

FAQ

Is open banking safe? Yes. Banks never share your password with the AISP; authentication happens in the bank's own SCA flow, and the AISP only receives a time-bounded access token. The AISP itself is licensed, regulated and supervised by a national authority and must hold professional indemnity insurance.

Can I revoke consent? Yes, at any time, in two places: inside the AISP/PISP app (which should expose a "disconnect bank" button) and inside your bank's online or mobile banking under "Connected services" / "Third-party access". Either action terminates data access immediately.

Why does my bank ask SCA so often? Two reasons: PSD2 requires SCA on every login after a short idle period and on every payment above 30 EUR (unless an exemption applies), and the 180-day consent renewal forces re-authentication for AISP connections.

Why don't UK banks work in EU apps? Because the UK left the EEA, UK banks are no longer under PSD2 obligations toward EU AISPs. Some aggregators bridge the two regimes via separate FCA permissions, but coverage is not automatic.

Do I pay for open banking? No. PSD2 explicitly bans banks from charging for the standard AISP/PISP APIs. Premium APIs introduced under PSD3 may carry fees, but only above and beyond the regulated baseline.

What if my bank's API is down? PSD2 requires banks to maintain a "fallback mechanism" (usually screen-scraping by the licensed AISP) when the API exceeds defined unavailability thresholds (typically 30 minutes of downtime in two consecutive hours). PSD3 is expected to replace fallbacks with hard uptime SLAs.

Sources

• Directive (EU) 2015/2366 (PSD2)
• Commission Delegated Regulation (EU) 2018/389 (RTS on SCA)
• European Commission proposal COM(2023)366 (PSD3 / PSR)
• EBA Guidelines EBA/GL/2017/08 (professional indemnity)
• DORA — Regulation (EU) 2022/2554
• Berlin Group NextGenPSD2 framework
• STET PSD2 API specification
• PolishAPI standard (Polish Banking Association)
• OBIE Read/Write API specification (UK)
• National competent authorities: BaFin, ACPR, Bank of Italy, Banco de España, DNB, KNF, Central Bank of Ireland