The Berlin Group API standard: how a German bank opens its accounts
The Berlin Group describes itself as a pan-European payments interoperability standards and harmonisation initiative, and its NextGenPSD2 framework is the API specification that most German banks implement for open banking. PSD2 required banks to open an interface but did not say what the interface should look like, so the market needed a specification or every bank would have invented its own.
This page goes below open banking in Germany, which names the standard and says what it is for. Here the subject is the specification level: the three service groups, the consent model, the three authentication approaches, and the uncomfortable fact that two banks implementing the same standard still need different code.
Who the Berlin Group is and what it publishes
The Berlin Group is an industry body of banks, central banks, payment associations, payment schemes and interbank processors operating in SEPA, organized in taskforces with supporting working groups for API experts, business evaluation and market communication. It is not a regulator and it issues no licenses. Its output is specifications, and a bank implements them because the market expects it, not because a supervisor ordered it.
Each framework comes as three kinds of document, all published free under a Creative Commons license: Operational Rules describe the service, the logical data model and the process flows as a business-to-business interface; Implementation Guidelines specify the interfaces in technical detail with the XML and JSON schemas; and OpenAPI files let a developer generate code. A team that reads only the guidelines misses the process rules, and a team that reads only the rules writes an interface nobody can call.
NextGenPSD2 and its three service groups
NextGenPSD2 covers exactly the three access-to-account services PSD2 created. Account Information Service, AIS, reads balances and transactions for a third party the customer authorized. Payment Initiation Service, PIS, starts a payment from the customer's account. Confirmation of Availability of Funds, sometimes written PIIS or CAF, answers a yes-or-no question about whether an amount is covered, which a card issuer uses before authorizing.
The specification is REST with JSON messages, secured with OAuth 2.0 and OpenID Connect, and it has grown well past the bare minimum over its versions: multi-currency accounts, standing orders, periodic payments and better error handling. The standards tracker at Fiskil counts around thirty countries implementing it, which is why a provider building for Germany gets most of Europe with the same code.
The consent model and the three authentication approaches
Consent is a resource in the API, not a checkbox. A third party creates a consent object describing what it wants to access and for how long, the customer authorizes it at the bank, and every later call references that consent. A consent has a lifetime and a scope, and the bank enforces both, which is why an expired consent produces an error and not a quietly empty response.
Strong customer authentication can happen three ways and the standard supports all three. In the redirect approach the customer is sent to the bank's own page or app and comes back afterwards. In the decoupled approach the customer approves in the bank's app on another device while the original session waits. In the embedded approach the authentication data passes through the API itself. Which one a bank offers decides how the checkout feels, and strong customer authentication covers the rules behind it.
Why two banks with the same standard still need different code
A specification leaves choices, and every choice a bank makes differently is integration work for the provider. Which authentication approach is offered. Which optional fields are populated. How long a consent lives before reauthentication. Which error codes come back for the same failure. Whether a batch payment is supported and in which format. None of these is a violation of the standard; all of them break a naive integration.
That is the business reason aggregators exist. A bank connecting to a few hundred German institutions directly maintains a few hundred sets of quirks, and a provider sells the abstraction over them. Each bank also runs a sandbox for testing before production access, and sandbox behavior is not always production behavior, which is where most integration timelines slip.
The openFinance API framework beyond PSD2
The Berlin Group's openFinance API Framework builds on the technology and infrastructure investments of NextGenPSD2 and adds standardized extensions beyond the regulatory PSD2 scope, so bank customers can reach their accounts for commercial premium services and enriched data, as the group states it. It covers broader data sources and more account types than PSD2 requires: savings, loans and investments beside the payment account.
On the payment side the premium extensions are the services a provider has always wanted and PSD2 never granted: blocking or reserving funds, deferring a payment, pay-by-loan with an integrated consumer credit, setting up a SEPA direct debit mandate. The framework provides the technical shape; the SPAA scheme provides the commercial terms. The two are designed to be used together, and the Berlin Group publishes a workplan for the services it intends to add.
What FIDA would require on top
FIDA, the EU regulation on financial data access, would extend compulsory access well past the payment account, to mortgages, savings, investments, insurance, pensions and creditworthiness data, and it would oblige firms to join financial data sharing schemes that set the standards and the compensation. That is a much wider surface than NextGenPSD2 covers.
For a German bank the sequence matters more than the detail. A bank that implemented NextGenPSD2 properly already has the consent machinery, the authentication plumbing and the API operations practice. FIDA would add data domains and a permission dashboard, and openFinance is the Berlin Group's bid to be the specification those schemes adopt. A bank with a half-built PSD2 interface will meet FIDA from a worse position.
What is the Berlin Group standard?
The Berlin Group standard, properly the NextGenPSD2 Access to Account framework, is a free API specification for the three PSD2 services: account information, payment initiation and confirmation of funds. It defines REST and JSON interfaces, a consent model and three strong customer authentication approaches, and it is implemented by banks in around thirty countries.
Is the Berlin Group standard mandatory?
No. PSD2 obliges a bank to provide an access interface but does not prescribe a specification. The Berlin Group is an industry initiative, not a regulator, and its documents are voluntary. The standard is dominant in Germany and much of continental Europe because the market converged on it, which has the same practical effect as a requirement without the legal force.
The Berlin Group standard and Finance Loop
Finance Loop is where the bank teams who built an XS2A interface meet the providers who consume a few hundred of them, which is the conversation that surfaces what a specification left open. Finance Loop is the meeting place for payments in Germany, with meetups and conferences on open banking, instant transfers and payment regulation. Finance Loop keeps those dates in its event calendar.
Finance Loop is a professional network and has the goal of driving the adoption of emerging technologies in finance, such as AI, tokenization, stablecoins, and DeFi. Finance Loop helps its members build skills and personal networks in these fields: Investment & Digital Assets, Payments & Digital Money, Digital Infrastructure & Sovereignty, and Risk & Compliance.