PSD2 API standards in Europe: Berlin Group, STET, UK Open Banking and the hubs
PSD2 required every bank in the EU to give licensed third parties access to payment accounts. It did not say how. The regulatory technical standards require a secure, documented, dedicated interface with a testing facility, but they stop short of a specification — and so the market wrote several.
For a PISP, this is the practical meaning of “European coverage”: not one integration, but a family of them.
Berlin Group NextGenPSD2
The most widely adopted standard in Europe, published by the Berlin Group, a long-standing interoperability initiative of European banks and payment processors. It is the norm in Germany and Austria, across the Nordic and Baltic countries, and widely used in the Netherlands, Belgium, Italy and much of central and eastern Europe.
Its defining feature is flexibility. NextGenPSD2 is a framework with many optional elements, and each bank chooses:
- The authentication approach — redirect to the bank, OAuth2, decoupled approval in the banking app, or embedded, where credentials pass through the third party’s interface.
- The payment products supported, such as
sepa-credit-transfersandinstant-sepa-credit-transfers. - Whether request signing is required, using the third party’s QSealC.
- How far payment status is reported after the payer approves.
Statuses use ISO 20022 codes — RCVD, ACTC, ACSP, ACSC, RJCT and so
on — which helps. But two Berlin Group banks can behave so differently that the
shared standard saves less work than its name suggests.
STET
France wrote its own standard, published by the interbank processor STET and adopted by most French banks — and by some banks elsewhere with French parents, notably in Belgium. STET covers the same services as Berlin Group with a different resource model: payments are created as payment requests, and some banks add a separate confirmation step after the payer has approved. Signing rules vary by bank. An integration written for Berlin Group does not work against STET.
UK Open Banking Standard
The United Kingdom took the opposite route to the continent. Its competition regulator required the largest banks to implement a single detailed specification, with a mandated security profile based on FAPI and a central directory that issues the certificates participants use.
The result is the most consistent Open Banking estate in Europe. A payment is made in two steps — a consent the payer approves, then a payment order against that consent — and settles over Faster Payments in sterling. The standard also introduced variable recurring payments, which have no direct equivalent under PSD2 on the continent.
Polish API
Poland’s banks published a common standard through the Polish Bank Association. It is specific to the Polish market, with its own message formats and security conventions, and domestic payments in złoty run over Polish rails.
National hubs
In some countries the banks did not build interfaces individually at all.
- Spain — Redsys. Most Spanish banks, including the largest, expose their PSD2 interfaces through the Redsys hub, which follows a Berlin Group profile with hub-specific routing for each bank.
- Portugal — SIBS. The national processor operates a shared API platform used by most Portuguese banks.
- Italy — CBI Globe and Luxembourg — LUXHUB play similar roles for many banks in their markets.
A hub makes broad national coverage efficient, because one technical integration reaches many banks. It does not make those banks identical: each keeps its own authentication journey and its own rules on required fields.
Bank-specific APIs
Finally, a number of banks — often the largest or the most digital — publish their own PSD2 APIs that follow no shared standard, or follow one loosely. The Netherlands is a good example of a market where Berlin Group implementations and bank-specific APIs sit side by side.
The standards at a glance
| Standard | Where you meet it | Character |
|---|---|---|
| Berlin Group NextGenPSD2 | Germany, Austria, Nordics, Baltics, Netherlands, Belgium, Italy and more | A flexible framework; wide variation between banks |
| STET | France; some Belgian banks | A distinct resource model; per-bank signing and confirmation rules |
| UK Open Banking Standard | United Kingdom | One detailed specification; very consistent |
| Polish API | Poland | National standard and domestic rails |
| National hubs | Spain, Portugal, Italy, Luxembourg | One integration, many banks — each still individual |
| Bank-specific APIs | Scattered, notably the Netherlands | Bespoke, bank by bank |
What differs even within one standard
The standard a bank follows predicts less than you would hope. The differences that consume engineering time are mostly beneath it:
- which authentication approaches are offered, and how they behave on mobile;
- which “optional” fields are rejected when absent;
- whether the payer must type an IBAN, or can choose an account at the bank;
- how the bank signals a payer’s cancellation, as opposed to a failure;
- where status reporting stops — some banks never confirm beyond “accepted”;
- how the sandbox differs from production.
These are also the things that change without notice, which is why Open Banking connections break.
What this means for a PISP
Coverage is a portfolio of integrations with a permanent maintenance cost, and the cost scales with the number of banks rather than the number of standards. A PISP can build that portfolio or buy it. MVP Payments normalises every standard above the line — one API, one status model, one signed webhook format — so that the standard a bank follows never reaches your code. See live coverage by country.