Is there a single PSD2 API standard?

No. PSD2 mandated the outcome (access to accounts with the customer's consent) but never the design, so the industry built several competing standards. A bank can be fully PSD2-compliant and still look nothing like the bank next door.

What is the Berlin Group NextGenPSD2 standard?

It is the most widely adopted European open-banking API standard, used across most of Germany, Austria, the Nordics, Iberia, Italy and much of the EEA. It is the closest thing to a common language, but it is a framework rather than a rigid rulebook, so implementations still vary.

Why do two banks on the same standard still differ?

Because most standards are frameworks, not rigid rulebooks. Banks diverge on which version they run, which optional fields they populate, the bank-specific extensions they add and how strong customer authentication works. Authentication is often the single biggest difference.

What is the difference between a bespoke and a premium bank API?

Bespoke describes where an API comes from (a bank's own design, built outside any shared standard). Premium describes what it does (services beyond the PSD2 baseline). A premium service can be a fully bespoke API or an extension bolted onto an otherwise standard one.

Why every bank's API is different

You have probably heard that every bank’s API is different and that connecting to a new one is rarely as simple as “they support open banking, so it will just work.”

There are lots of reasons for this. One sits underneath all the others: there was never a single standard.

Short answer: PSD2 forced banks to open up but never said how, so the industry built several competing standards. And even two banks on the same standard diverge in versions, optional fields and authentication. That is why “supports open banking” tells you almost nothing about the work an integration will actually take.

Here is the longer why.

The law set the goal, not the design

PSD2, the EU’s second Payment Services Directive, is the reason these bank APIs exist at all.

It forced banks to open up access to accounts, with the customer’s consent, for three things: reading account information, initiating payments and checking whether funds are available.

What it did not do was say how.

It described the outcome and left the engineering to the industry. That one decision is why there is no single “PSD2 API.”

Instead, groups of banks and national communities each built their own way of meeting the same legal requirement. A bank can be fully compliant and still look nothing like the bank next door.

The standards that filled the gap

The result is a handful of competing standards. They fall into three rough camps.

Camp	What it is	Where you meet it
Pan-European default	Berlin Group NextGenPSD2, the closest thing to a common language	Most of Germany, Austria, the Nordics, Iberia, Italy and much of the rest of the EEA
National standards	Countries that coordinated their own approach instead of adopting the pan-European one	France on STET (and some Belgian banks), Poland on PolishAPI, Slovakia on the Slovak Banking API
Bespoke (proprietary)	A bank’s own API, built outside any shared standard	One specific bank at a time

The national standards are why the same banking group can behave differently from one country to the next. The standard itself can change at the border.

The bespoke ones can be genuinely excellent. They are just specific to one bank, so nothing you learn about them carries over to the next.

A quick note on terminology, because it trips people up. “Bespoke” is about where an API comes from: the bank built its own instead of adopting a shared standard. “Premium” is about what it does: services beyond the PSD2 baseline. The two often coincide, but not always. A premium service can be a fully bespoke API, or just an extension bolted onto an otherwise standard one.

Even the same standard is not uniform

Here is the part that surprises people. Two banks on the same standard still are not interchangeable.

Most standards are frameworks rather than rigid rulebooks, so banks drift apart in ways that create real work:

Versions. Banks adopt different releases and upgrade on their own schedule.
Optional fields. Standards leave many fields optional. One bank fills them in, the next leaves them blank.
Extensions. Banks bolt on their own features, especially for premium products the standard never described.
Authentication. How a customer proves who they are (Strong Customer Authentication) varies a lot between banks. It is often the single biggest difference.

So “every bank is different” is true on two levels. There are different standards between markets. Then there are different implementations inside a single standard.

Why this matters

If you are wiring up banks across Europe, the takeaway is that “supports open banking” is the start of the question, not the answer.

What actually decides the effort is which standard a bank runs, which services are genuinely live, how authentication works and how far the bank has gone beyond the regulatory minimum.

That gap is why I built BankSnipe. I wanted to bring some visibility to all of this, and to leave behind a resource for the next generation of treasurers who are builders, the people who will be wiring these connections together for real.

Every bank in the index shows its API standard, the services it offers and a 1 to 5 maturity rating. You can see at a glance how far along a bank really is and where it differs by country, before you commit to it.

Knowing which standard each bank speaks is the first step to understanding why they are all so different.