Open banking explained: AIS, PIS and variable recurring payments

Open banking lets authorised third parties access bank account data or initiate payments, with the account holder’s consent, through the bank’s interfaces. In practice it splits into two core services — account information (reading data) and payment initiation (moving money) — plus emerging recurring models such as variable recurring payments. All of it rests on consent and strong customer authentication, and all of it is uneven: coverage and API quality differ by bank and country. This guide explains the roles, the journeys and the regulatory position, keeping current law separate from forthcoming law.

Legal and regulatory status was reviewed on 7 July 2026.

Account information services

An account information service (AIS) reads account data — balances, transactions and account details — on behalf of a consenting user. It is read-only: an AIS does not move money. Providing this service is a regulated activity under the current EU payments framework 1. Typical uses include financial dashboards, affordability checks and account verification.

Payment initiation services

A payment initiation service (PIS) initiates a credit transfer from the user’s bank account, with consent, without handling a card. The user authenticates with their own bank, which executes the payment. PIS enables account-to-account payments as an alternative to cards, and is regulated under the current framework 1.

Account servicing PSP

The account servicing payment service provider (ASPSP) is the bank or institution that holds the customer’s account and exposes the interfaces AIS and PIS providers use. The ASPSP authenticates the user and executes payment instructions. API quality, uptime and behaviour vary considerably between ASPSPs, which is a primary source of coverage fragmentation.

Consent

Consent is the foundation: the user must explicitly authorise what data is accessed or what payment is made, for what purpose and for how long. Consent is granular and time-bound, and it can be withdrawn. Designing clear consent flows — and managing consent lifecycles — is central to any open-banking product.

Strong customer authentication

Strong customer authentication (SCA) requires the user to authenticate, generally using multiple independent factors, and is governed by regulatory technical standards 2. SCA is applied by the ASPSP during AIS and PIS journeys. It protects users but adds friction, so journey design must balance security and completion rates.

Redirect, decoupled and embedded journeys

Authentication journeys take different conceptual shapes. In a redirect journey the user is sent to their bank’s app or site to authenticate; in a decoupled journey they approve in a separate channel such as a banking app; in an embedded journey credentials are handled within the flow subject to the applicable rules. Availability of each pattern differs by ASPSP and affects completion rates.

Data aggregation

Aggregation combines account data across multiple banks into one view via AIS. The value depends on breadth of coverage and data quality. Because ASPSP APIs differ, aggregation providers do substantial work to normalise data — see the add open banking data and account verification stack.

Transaction enrichment

Raw transaction data is often terse and inconsistent. Enrichment cleans and categorises it — identifying merchants, categories and recurring patterns. Enrichment quality varies by provider and materially affects downstream features like budgeting or affordability assessment. It is an added layer on top of AIS, not part of the bank’s data itself.

Account verification

AIS can confirm that a user controls an account and check ownership details, which supports onboarding and payout setup. This is a common, lower-complexity use of open banking data and complements name-checking approaches such as Verification of Payee — see instant payments and Verification of Payee.

Payment initiation

Beyond one-off payments, PIS underpins checkout, account funding and bill payment as an account-to-account alternative to cards. Settlement typically rides existing rails such as SEPA credit transfer or instant transfer — see SEPA payment rails explained. Confirm which rail a PIS payment actually uses, as it drives speed and finality.

Recurring and variable recurring models

Recurring payment needs range from fixed schedules to variable recurring payments (VRP), where a user consents to a series of payments within agreed limits (for example a maximum amount or frequency). VRP can support use cases like automatic top-ups. Its availability and implementation differ significantly across banks and countries and should not be assumed uniform.

AIS, PIS and VRP compared

Capability	What it does	Moves money	Typical use
Account information (AIS)	Reads account data with consent	No	Dashboards, affordability, verification
Payment initiation (PIS)	Initiates a credit transfer with consent	Yes	Checkout, account funding, bill payment
Variable recurring payments (VRP)	Consented series of payments within agreed limits	Yes	Automatic top-ups, recurring transfers

Availability of each capability — and of VRP in particular — differs by bank and country, so treat this as a conceptual comparison rather than a coverage guarantee.

Coverage fragmentation

Open banking coverage is fragmented: not every bank exposes every capability, and API behaviour, uptime and data richness vary. A provider’s “coverage” figure can mask uneven quality. Test coverage against the specific banks and countries your users actually use, using the open banking provider category as a starting point.

API availability

ASPSP APIs differ in uptime, latency and error behaviour. Downtime at a bank directly breaks your flows for that bank’s customers. Understand how your provider monitors ASPSP availability, how it handles outages, and how failures surface to users.

Error and consent handling

Open-banking journeys fail in many ways: authentication drop-off, expired or withdrawn consent, and ASPSP errors. Handle each explicitly — prompting re-consent, retrying appropriately and giving users clear next steps. Poor error handling is a leading cause of low completion.

Reconciliation

For payments, reconcile initiated payments against settlement on the underlying rail, since PIS initiates but the payment settles separately. For data, manage refresh timing and consent expiry. Build reconciliation around the fact that initiation and settlement are distinct steps.

PSD2 current framework

The current EU framework for open banking is PSD2 1, supported by delegated rules including the SCA technical standards 2. The European Commission provides general context on payment services 3. Design to the current framework, not to anticipated changes.

PSD3/PSR forthcoming status

PSD3 and the Payment Services Regulation (PSR) reached political agreement in November 2025 but, per the Commission’s 19 May 2026 status update, the texts were not yet formally adopted, with final adoption and publication expected in Q4 2026 and most PSR provisions expected to apply 21 months after entry into force 4. They are forthcoming, not applicable law — do not build on the assumption that PSD3 or PSR is currently in force.

Provider-selection criteria

• Required services (AIS, PIS, VRP) confirmed for your product
• Coverage tested against the specific banks and countries your users use
• API availability, latency and error behaviour assessed
• Authentication journey patterns (redirect/decoupled/embedded) reviewed
• Consent lifecycle and re-consent handling designed
• VRP availability confirmed per market, not assumed uniform
• Reconciliation between initiation and settlement built
• Current-framework compliance responsibilities mapped, not future-law assumptions

Questions to ask providers

• Which of AIS, PIS and VRP do you support, and in which countries?
• How do you measure and report ASPSP coverage and API availability?
• Which authentication journeys do you support per bank?
• How is consent captured, stored, refreshed and withdrawn?
• Where VRP is offered, in which markets is it actually available?
• How do you handle ASPSP errors and consent expiry in the user journey?
• How do you help reconcile initiated payments against settlement?
• How do you track the current framework versus forthcoming PSD3/PSR changes?

Common failure modes

• Assuming VRP or any capability is uniformly available across Europe.
• Trusting a headline coverage figure without testing the banks your users actually use.
• Designing consent flows that users abandon, tanking completion.
• Treating PIS initiation as settlement and mis-timing reconciliation.
• Building to anticipated PSD3/PSR provisions as though they were current law.

What this does not cover

This guide explains open banking in general terms. It does not provide legal advice, determine your obligations under any current or forthcoming regulation, or assess any specific provider. Confirm current requirements with the applicable legislation and your provider, and treat PSD3/PSR as forthcoming.

FAQ

What is the difference between AIS and PIS?

AIS reads account data with the user’s consent and does not move money; PIS initiates a payment from the user’s account with consent. Both are regulated activities under the current framework 1.

Do open-banking payments avoid strong customer authentication?

No. The account holder authenticates with their own bank, and SCA applies as set out in the regulatory technical standards 2. SCA is central to the journey, not bypassed.

Is variable recurring payment support available everywhere in Europe?

No. VRP availability and implementation vary significantly across banks and countries. Confirm it for each market you target rather than assuming uniform availability.

Is PSD3 the current law for open banking?

No. PSD2 is the current framework 1. PSD3 and the PSR reached political agreement in November 2025 but were not yet formally adopted as of the Commission’s 19 May 2026 update, with adoption expected in Q4 2026 4.

Why does open-banking coverage vary so much?

Because each account servicing bank exposes its own interfaces with differing capabilities, uptime and data quality. Providers work to normalise this, but real coverage and reliability still differ by bank and country.