SPAA: Europe's Paid Open Banking Scheme, and the Register That Explains Its Problem

Two things make SEPA Payment Account Access worth an operator's attention. The first is that it inverts the commercial logic of PSD2. The second is that you can check how well that is going in about a minute, from a file the European Payments Council publishes itself.

What SPAA actually is

SPAA is an EPC scheme — rules, practices and standards — created in line with the June 2021 report of the Euro Retail Payments Board's working group on a SEPA API access scheme. The rulebook describes its subject as

the exchange of payment accounts related data (i.e. data Assets) and facilitates the initiation of payment transactions (i.e. transaction Assets) in the context of 'value-added' ('Premium') API-based services provided, in an asymmetric way (client/server), by Asset Holders (i.e. Account-Servicing Payment Service Providers (ASPSPs)) to Asset Brokers

Two clarifications the rulebook makes about itself are worth carrying, because they head off the two most common misreadings:

The Scheme covers a messaging functionality. It is not a payment means or a payment instrument, but a way to transport information in relation to payment accounts and transactions.

It is not a rail. It rides on existing rails. And it is a scheme in the EPC sense — adherence, a rulebook, a register — not a product, a standard, or an API specification. The API specifications are developed separately by standardisation initiatives against the rulebook's requirements.

The four actors, two of which are not participants

This vocabulary is used precisely throughout the rulebook, and getting it wrong will make every other document confusing.

Note the rulebook's own aside that an Asset Holder "could also take up the role of an Asset Broker" — the roles describe functions, not institution types.

If you are a merchant, you are almost certainly an Asset User, which means you are a beneficiary of the scheme and not a party to it. Your relationship is with a broker, and your leverage is commercial rather than scheme-based.

The commercial inversion, which is the point

PSD2 obliges account-servicing PSPs to expose a baseline of access, and does not let them charge third parties for it. SPAA covers what sits above that line, and lets them charge.

The rulebook draws the boundary explicitly. Basic services are those regulated under PSD2. Premium services are either:

• services building on PSD2-regulated ones "but going beyond the minimum regulatory requirements via the combination with (a) so-called Premium feature(s)", or
• PSD2-scope services that a bank does not make available through its online banking interfaces, but does provide through a SPAA API

And it gives a worked example that makes the distinction concrete: a one-off payment is a basic service, but combined with a premium feature such as a payment certainty mechanism, it becomes a premium service.

That example is the whole scheme in miniature. The underlying capability is already mandated and free. What you pay for is the thing that makes it commercially usable — in that case, knowing the payment will actually complete.

What is in the scheme

The rulebook organises the scheme into transaction assets, data assets and premium features.

Transaction assets include one-off payments, future dated payments (both warehoused with a defined execution date and dynamic), recurring payments (fixed-amount warehoused and dynamic), payment to multiple counterparties, personal finance management automated transfers, and refunds.

Data assets include the list of payment accounts, the list of payment account transactions, the list of cards, and the list of card transactions.

Premium features are the modifiers that turn a basic asset into a premium service. The rulebook's datasets cover a payment certainty mechanism request, a request for supporting account information and its response, SCA approach preferences, a request not to apply an SCA exemption, and account replacement during authentication.

The scheme also specifies a mechanism to request a payment with transaction fees not borne by the payer, and four eligible SCA approaches — which are worth their own section, because one of them moves liability.

For anyone who has built against PSD2 APIs, the notable entries are dynamic recurring payments and payment certainty: precisely the two gaps that make baseline PSD2 payment initiation awkward for merchant use cases.

Authentication, and the one approach that moves liability

The rulebook lists four eligible SCA approaches. Three are delivery mechanics; the fourth reallocates who pays for fraud.

Delegated SCA is the one that matters commercially. The rulebook describes it as

an arrangement (e.g., a bilateral agreement) whereby the Asset Broker requests the Asset Holder to delegate its own SCA obligation. Upon Asset Holder's agreement, the SCA is then performed by the Asset Broker who takes the liability of fraudulently authorised transactions.

Read the second sentence carefully. The broker does the authenticating and carries the liability for transactions that turn out to be fraudulently authorised.

That the loss is one the broker would not otherwise bear is not an assumption — the rulebook says so elsewhere, describing the PSD2 default position: "In the context of PSD2 [9], the Asset Holder, being liable and having to support the consequences of a dispute, is the actor who usually decides whether or not to apply an SCA exemption." The holder is the party normally carrying it.

But be precise about what kind of obligation this shift is. The rulebook's own liability chapter draws a boundary around itself:

A Participant's liability under the Rulebook is limited to the operation of SPAA exchanges and shall be kept separate from any liability arising from the subsequent payment.

Fraud loss on an authorised transaction is liability arising from the subsequent payment. So it sits outside the Rulebook's own liability provisions, which cover breach of the Rulebook and negligent acts relating to the SPAA exchange itself. The delegated-SCA shift is therefore what its own definition says it is — an arrangement, a bilateral allocation between two participants — and not a scheme-enforced entitlement you can invoke through the scheme's machinery. Put the allocation in the contract, because the rulebook is explicit that its own liability rules are not where it lives.

The rulebook walks through a sample flow — its own word, and used for all four approaches — in three steps. The middle one is the operationally interesting part. The Asset Broker authenticates the payer itself, then sends the Asset Holder signed proof of that authentication, which the rulebook says embeds, for example:

• the unambiguous identification of the payer
• the timestamp of the authentication
• the strength of the authentication
• the category of each authentication factor challenged
• the Asset Broker's relevant claims

The Asset Holder then checks the proof and performs the request — "after optionally conducting a risk assessment." That word optionally is doing real work: accepting delegated SCA does not oblige the holder to stop applying its own risk logic.

Three qualifications that stop this being a service you can demand

It cannot be demanded. The rulebook is explicit that delegated SCA "is therefore strongly encouraged but it shall however not be mandated given the legal and contractual obligations (e.g., liability shift) related to the outsourcing of this functionality." An Asset Holder can decline. The word "arrangement" in the definition, and the parenthetical "e.g., a bilateral agreement", carry the weight — this is negotiated, not switched on.

But the holder should support something. The same section says that "at least one of the eligible SCA approaches as described in section 2.3.3. should be implemented by the Asset Holder adhering to the Scheme." Note the verb. The rulebook uses shall for binding duties elsewhere and should here, so read this as the scheme's expectation rather than a hard obligation — a participating holder is expected to offer an approach, and certainly does not owe you this one.

Payer identification may get harder, not easier. A footnote to the SCA section notes: "In case of delegated SCA further requirements on payer's identification may apply." The rulebook does not enumerate them there, and this article does not guess at what they are.

The other three approaches

• Decoupled — authentication happens on a separate device or app, woken by the Asset Holder from the broker's API request. The rulebook distinguishes app2app (m-commerce), web2app (e-commerce) and POS2app (in-store).
• Redirection — the broker's app launches the payer's authentication app, which treats the device itself as the possession factor.
• Embedded — with or without a signed payment request.

For an operator choosing between them, the practical split is that delegated SCA is the only one that changes who bears fraud loss. The other three change how the payer is challenged rather than who pays when it goes wrong — and note that embedded does not necessarily move the payer anywhere: in the rulebook's sample flow for embedded without a signed payment request, the payer types the one-time password "as a possession factor within the Asset Broker's interface".

How the money works

The EPC published Default Fees version 1.0 on 22 November 2023. The model has two components:

• Default asset fees for the premium assets and premium features an Asset Holder exposes to an Asset Broker
• A default API access fee for the use of the premium SPAA API itself

Three properties matter more than the numbers.

The schedule is a fallback, not a tariff. The fees apply between participants "unless Asset Holders and Asset Brokers have bilaterally agreed on a different (lower) amount." Bilateral agreement moves the price down, not up.

The premium API can carry basic traffic, and only the API use is charged. The document states that where the premium API is used to reach basic PSD2-scope services, "only the use of the 'premium' API will be subject to scheme-based remuneration." It also says explicitly that the availability of the premium API does not prevent participants continuing to use their existing PSD2 access-to-account APIs for basic services.

Customer pricing is out of scope. The fees are "inter-scheme participants fees only", and the basis and level of charges to end customers are "entirely a matter for individual scheme participants and their customers." Nothing in the scheme tells a broker what to charge a merchant.

The default fee schedule, version 1.0

These are the amounts published in EPC270-23, in euro, per call.

Two things to read off that table before the numbers themselves.

First, the magnitudes. Roughly one to four euro cents per call, with the API access fee charged alongside the asset fee. Whatever the barrier to SPAA has been, headline pricing is not obviously it — these are wholesale numbers of the same order as the UK's published VRP wholesale model, though the two schemes are not otherwise comparable.

Second, what is missing from the list. There is no default fee for the list of payment accounts or the list of payment account transactions — the two payment-account data assets — nor for the warehoused, fixed-amount variants of future dated and recurring payments. Only the dynamic variants are priced. The schedule prices a subset of what the rulebook specifies, and this article does not speculate about why.

These figures are version 1.0, issued 22 November 2023, and should not be treated as current. The document says of itself that the fees were "expected to be revised early next year and on a periodic basis" to reflect market developments. Nearly three years on, check the current default fees document before putting any of these into a model.

The register, and what it says

The scheme rulebook has been effective since 30 November 2023. The EPC's Register of Participants covers SPAA alongside the SEPA credit transfer, instant, direct debit, request-to-pay and other schemes, and publishes a per-scheme export.

The SPAA export, as at 28 August 2026, contains five participants.

Every one is an Asset Broker. No Asset Holder appears. None carries a scheme leaving date, so this is not attrition — it is a supply side that has not arrived.

Read that against the scheme's own design. SPAA works when Asset Holders expose premium assets to Asset Brokers for a fee. The brokers have adhered: the register is a roll-call of the significant European open-banking connectivity providers. The banks that would have to expose and price the premium assets have not.

This is the fact to plan around, and it is the one most likely to change. It is also trivially checkable — download the SPAA export from the register page and count the roles. Do that rather than trusting this article's count, or anyone else's.

Why the supply side is optional here

The asymmetry has a structural cause worth stating plainly. PSD2 baseline access is a regulatory obligation: a bank exposes it because it must. SPAA participation is contractual: a bank exposes premium assets because it chooses to, having decided the fee income justifies the build and the ongoing service commitment.

The scheme was designed to make that choice attractive — a governed rulebook, harmonised specifications, reachability across SEPA and a default price so nobody has to negotiate from zero. On the current register, that has not yet been enough.

None of which makes the scheme irrelevant. It makes it a watch item with a real specification rather than a capability you can currently buy.

What an operator should actually do

• Learn the vocabulary before reading anything else on this. Asset Holder, Asset Broker, Asset Owner, Asset User. Vendor material uses these terms loosely and the rulebook does not.
• Check the register before believing a claim. If a provider offers SPAA-based premium access, ask which Asset Holder they hold a scheme agreement with, then look that name up. Five participants is a short list to check against.
• Do not model SPAA fees into a business case yet. The default schedule is a fallback that bilateral agreement moves downward, the published version is from 2023 and was expected to be revised, and with no Asset Holders registered there is no counterparty to agree anything with.
• Do separate the capability from the scheme. Dynamic recurring payments and payment certainty are real merchant needs. If a bank or broker offers them today, it is offering them commercially, outside SPAA — which is permitted, and which is a different contract with different governance.
• Keep the UK separate. The UK's commercial variable recurring payments model is a distinct scheme under distinct governance with its own published pricing. See variable recurring payments and open banking billing and open banking VRP in the UK and EU for that side. This article does not carry UK figures across, and neither should you.
• Watch the regulatory track separately. SPAA is an industry scheme built on PSD2, not a regulatory instrument. For where EU payments regulation is going, see the PSD3 and PSR implementation checklist — this article makes no claim about what PSD3 or the Payment Services Regulation will require of SPAA.

The honest summary

SPAA is a genuinely well-built answer to a real problem: PSD2 gave Europe mandatory access without a business model, and the capabilities merchants actually want sit just outside what PSD2 compels. A governed scheme with default pricing, harmonised specifications and SEPA-wide reachability is a sensible way to close that gap.

It has been effective since November 2023. Five participants have adhered, all of them brokers, and the newest readiness date is December 2024.

The specification is worth reading. The scheme is not yet something you can build a dependency on, and the register is the fastest way to know when that changes.