Open Banking APIs: UK OBIE vs Berlin Group vs STET

A UK bank API and a German bank API both claim to implement "PSD2 open banking", and almost nothing below the HTTP layer is the same. The UK standard rejects a payment consent with a four-letter ISO code, the Berlin Group one answers with a lower-case English word, and the French one signs a different set of headers with a different certificate type.

I have spent enough time against all three to know the comparison pages that rank for this query are nearly all written by aggregators selling the integration. They say "4,000 banks" and "90 days" and stop. This guide covers what you actually hit in code: version numbers with dates, consent endpoints, SCA approaches, status enums, security profiles, and the reauthentication rule that differs between the UK and the EU.

What Are the Open Banking API Standards in the UK and EU?

PSD2 required banks to open account and payment access to licensed third parties, but it never specified an API. Three standards filled the gap:

Poland (PolishAPI, versions 2.1.4 and 3.0.1 released 17 June 2025), Czechia (Czech Open Banking Standard v7.0, valid from 27 March 2024) and Slovakia (Slovak Banking API Standard 2.1, from 2021) run national standards that borrow heavily from Berlin Group. The Berlin Group itself claims "more than 80% of European banks"; I could not find an independent count, so treat that figure as self-reported.

Two things stand out from the version column. STET has not shipped a release in four years. The UK standard, by contrast, has had three releases since April 2026 and the September Update 1 changed behaviour that integrations depend on: it made the x-jws-signature header optional in the Swagger definitions, specified HTTP 422 for a duplicate idempotency key, and removed CANC from the VRP consent status list.

Which Version Is Current: OBIE v4.0.1, NextGenPSD2 1.3.16 and STET 1.6.3?

The ISO alignment is the part that breaks parsers. Status fields that used to carry readable names (AwaitingAuthorisation, Authorised) now carry four-character ISO codes (AWAU, AUTH). The consultation draft had also renamed the field itself to StatusCode; Open Banking Ltd reverted that after feedback, so the field is still called Status but its values changed. Error codes moved to four-character ISO codes too, and the top-level error code and message fields are now optional and deprecated.

v3.1.11 is still listed on the specification site alongside v4.0 and v4.0.1. The deprecation policy leaves retirement of an old version to each bank's discretion based on usage metrics, so expect to run v3.1.11 and v4 clients side by side for a while yet.

How Does the Consent Flow Differ Between OBIE, Berlin Group and STET?

All three are two-step: create a consent or payment resource, send the user to authenticate, then act. The resources and the fields are not interchangeable.

{
  "Data": {
    "Permissions": ["ReadAccountsDetail", "ReadBalances", "ReadTransactionsDetail"],
    "ExpirationDateTime": "2027-04-13T00:00:00+00:00",
    "TransactionFromDateTime": "2026-01-01T00:00:00+00:00",
    "TransactionToDateTime": "2026-10-13T00:00:00+00:00"
  },
  "Risk": {}
}

{
  "access": {
    "accounts": [{ "iban": "DE89370400440532013000" }],
    "balances": [{ "iban": "DE89370400440532013000" }],
    "transactions": [{ "iban": "DE89370400440532013000" }]
  },
  "recurringIndicator": true,
  "validUntil": "2027-04-13",
  "frequencyPerDay": 4,
  "combinedServiceIndicator": false
}

Every Berlin Group call carries X-Request-ID (a UUID). Consent and payment initiation also require PSU-IP-Address, and TPP-Redirect-URI is required whenever TPP-Redirect-Preferred is true or absent. Payments go to POST /v1/{payment-service}/{payment-product}, where the service is one of payments, bulk-payments or periodic-payments and the product is one of sepa-credit-transfers, instant-sepa-credit-transfers, target-2-payments or cross-border-credit-transfers. POST /v1/funds-confirmations is a mandatory endpoint.

Which SCA Approaches Does Each Open Banking Standard Support?

The embedded approach is the sharpest difference. Berlin Group allows a TPP to collect the user's bank credentials and OTP and pass them through the API, and a meaningful number of German and Austrian banks use it. The UK standard never permitted it; the Customer Experience Guidelines push hard on app-to-app redirect instead, with the explicit rule that the bank must not insert an app-chooser screen between the TPP and biometric authentication.

If you are building one abstraction over all three, the Berlin Group _links object is where the SCA approach is discovered at run time. A consent response may contain scaRedirect, scaOAuth, startAuthorisation, startAuthorisationWithPsuAuthentication and several more, and the bank picks. OBIE tells you the approach through the bank's well-known OpenID configuration instead, which you can resolve before the first request.

What Payment Status Codes Do the Open Banking APIs Return?

Since v4, OBIE and Berlin Group share the ISO 20022 payment status code set, which makes the two easier to reconcile than they were in 2023.

A UK domestic payment starts at RCVD or RJCT, then moves through PDNG, ACTC, PATC, ACCP, ACFC, ACSP, ACWC, ACSC, ACWP, ACCC, BLCK and RJCT. The terminal success state for a Faster Payment is ACSC (settlement completed). Consents use a separate enum: AWAU, AUTH, RJCT and COND for payments, with CANC and EXPD added for account-access consents. Multi-authorisation corporate accounts expose a third enum, AWAF, AUTH, RJCT.

Berlin Group's transactionStatus uses the same ISO codes (RCVD, PDNG, ACTC, ACCP, ACFC, ACSP, ACWC, ACWP, ACSC, ACCC, RJCT, CANC, PATC), but its consentStatus does not: it is received, rejected, valid, expired, revokedByPsu or terminatedByTpp. Mapping AUTH to valid is easy. Mapping expired is not, because the Berlin Group consent expires on validUntil while a UK consent can be open-ended and dies on the 90-day reconfirmation instead.

The practical rule I apply: treat ACSC and ACCC as money moved, ACSP and ACWC as in flight, and anything else as not done. Do not treat ACCP (accepted customer profile) as success. It means the bank liked the payload, not that funds left the account.

Is It 90 Days or 180 Days? AIS Reauthentication in the UK vs the EU

This is the fact that the aggregator comparison pages get wrong most often, and it is wrong in both directions.

In the EU, Delegated Regulation (EU) 2022/2360 inserted Article 10a into the SCA RTS. Since 25 July 2023 a bank must not apply SCA when an AISP reads balances or transactions from the last 90 days, provided the user performed SCA on first access and no more than 180 days have passed since the last SCA. So the EU cycle is 180 days, and it is a bank-side exemption the bank must offer.

In the UK the FCA took a different route in PS21/19 (29 November 2021). It created an Article 10A exemption so the bank does not need to re-run SCA every 90 days, but it moved the obligation to the TPP: under Article 36(6) the AISP must reconfirm the customer's consent at least every 90 days, and the bank's use of the exemption is voluntary. The amendments came into force on 26 March 2022.

The engineering consequence: in the EU you schedule a bank redirect every 180 days. In the UK you build your own consent-reconfirmation UI that fires every 90 days and never has to touch the bank, as long as the bank has adopted the exemption. If your code assumes "90 days then redirect" for both, your UK users see an unnecessary bank journey and your EU users get cut off three months early.

FAPI, eIDAS and OBWAC: How the Security Profiles Differ

The UK detached JWS is the most specific of the three. The header is an unencoded-payload JWS (RFC 7797) whose protected header must carry http://openbanking.org.uk/iat, http://openbanking.org.uk/iss in the form {org-id}/{software-statement-id}, http://openbanking.org.uk/tan set to openbanking.org.uk, and a crit array naming those claims. Get the crit array wrong and a compliant verifier must reject the message, which is the single most common cause of a 400 on first UK payment.

Berlin Group's signature is the older IETF HTTP Signatures draft, not JWS, and it is conditional: the bank declares whether it requires it. STET signs with JWS but over a different canonical string. Three signature schemes, one abstraction layer. Budget for it.

Certificates are the other trap. Since 1 January 2021 the UK issues its own OBWAC and OBSeal certificates through the Open Banking Directory, and legacy Open Banking certificates stopped working on 30 June 2021. eIDAS certificates are accepted in the UK but the Directory guidance now restricts them to TPPs that are not UK-authorised. In the EU, the EBA's opinion recommends banks accept QWAC and QSealC in parallel, and the bank chooses. There is no EU equivalent of the UK Directory; the EBA register has no certificate data, so PRETA's Open Banking Europe directory and Konsentus Verify fill that role commercially.

Which Payment Products Can You Initiate Through Each API?

VRP is the UK-only product and the one with commercial weight in 2026. A consent carries ControlParameters with MaximumIndividualAmount and PeriodicLimits (Day, Week, Fortnight, Month, Half-year, Year, aligned to Consent or Calendar), and non-sweeping consents are only allowed where the bank has a contract with the PISP. I covered the field-level traps in the VRP API guide. The EU has nothing comparable in the base standard; the Berlin Group openFinance framework and the EPC's SPAA scheme were meant to supply it, and I come to how that is going below.

Open Banking Adoption in the UK vs the EU in 2026

The UK publishes monthly numbers, the EU does not, and that asymmetry says a lot about the two governance models.

Open Banking Ltd's June 2026 figures: 2.81 billion API calls in the month, 18.81 million user connections, 40.16 million payments (32.43 million single domestic plus 7.73 million sweeping VRP), an average response time of 349 ms and weighted availability of 99.80%. The programme has now passed one billion cumulative payments and 100 billion cumulative API calls. Impact Report 7 (May 2025) put active users at 13.3 million, or 18.4% of the adult population.

Nobody publishes equivalent EEA-wide numbers. Berlin Group is a standards body with no monitoring mandate, and NCAs do not aggregate API traffic. That is why the UK has a comparison baseline and the EU has vendor estimates.

Governance is also changing in the UK. The Data (Use and Access) Act received Royal Assent on 19 June 2025. The FCA's FS25/4 (8 August 2025) settled that a not-for-profit company limited by guarantee, the "Future Entity", will take over standard-setting from Open Banking Ltd, with the Joint Regulatory Oversight Committee wound down. HM Treasury's "Modernising payment services" consultation ran from 14 July to 6 October 2026 and proposes a statutory right of access for VRP and FCA powers over API standards and pricing. The FCA has said it will consult on the long-term framework before the end of 2026. Commercial VRP went live under the UK Payments Initiative scheme this year, with 31 firms signed up and phase one scoped to utilities, financial services and government payees.

Will Berlin Group openFinance Replace NextGenPSD2? My Prediction

This section is opinion, so treat it as such.

The Berlin Group has moved its energy to the openFinance API Framework: a "V2 Suite" covering Core PSD2 Compliance, Request to Pay, Premium Payments with reservation of funds, Push AIS, Extended AIS, Mandate Services and Document Services, with a 2026-2027 workplan published in January 2026. It is contract-based, QWAC-based, and designed to carry premium (paid) APIs on top of the free PSD2 baseline. The EPC's SPAA scheme was supposed to be the commercial wrapper for those premium APIs. By September 2025 SPAA had five demand-side participants, zero asset holders (banks), a pilot that never happened, and a workplan on hold. The January 2026 minutes show the scheme being steered towards a federated model that converges with Berlin Group openFinance and Germany's giroAPI, with no mandatory default fees.

My read: NextGenPSD2 1.3.x is now frozen in all but name and will remain the free compliance layer for a decade, the same way ISO 8583 persists under card APIs. openFinance will not replace it; it will sit alongside it as the paid layer, and the EU will end up with the same two-tier shape the UK has with sweeping VRP (free, mandated) and commercial VRP (paid, contracted). The difference is that the UK got there through a regulator-run programme with published metrics, and the EU is trying to get there through a scheme with no banks in it. The PSR's mandatory dedicated-interface and dashboard rules will raise the floor from 2028 at the earliest, but they will not create a premium market. Only bank-side commercial incentive does that, and SPAA's membership list shows how little of it exists.

If you are choosing where to invest integration effort: the UK standard is the one with a roadmap, a conformance suite and release notes every quarter. Berlin Group is the one with coverage. STET is the one you implement once, for France, and never revisit.

What This Means for Developers Integrating Open Banking APIs

1. Pin the spec version per bank, not per standard. A UK bank may be on v3.1.11, v4.0 or v4.0.1, and the status enum differs between v3 and v4. Resolve the version from the bank's discovery document and keep one deserialiser per major version. 2. Model status as ISO codes internally. Both OBIE v4 and Berlin Group emit ISO 20022 payment status codes. Map STET and v3.1.x readable names into the same set at the edge, and treat only ACSC and ACCC as settled. 3. Keep two reauthentication timers. EU: SCA every 180 days, bank-side. UK: consent reconfirmation every 90 days, TPP-side. Store the jurisdiction on the consent record, not on the bank, because a non-UK TPP on a UK bank follows UK rules. 4. Implement three signature schemes behind one interface. UK detached JWS with the crit claims, Berlin Group HTTP Signatures with Digest, STET JWS over the request target. Unit test each against the published canonicalisation rules; a 400 from a signature failure carries almost no diagnostic detail. 5. Discover the SCA approach at run time for Berlin Group. Parse the _links object on every consent and payment response and branch on it. Never hardcode redirect. 6. Send PSU-IP-Address on every Berlin Group initiation call and x-fapi-customer-ip-address on UK calls when the user is present. Omitting the IP marks the call as unattended and burns one of the frequencyPerDay slots. 7. Read the UK Update 1 release notes from 18 September 2026 before your next deploy. The optional x-jws-signature in Swagger, HTTP 422 on duplicate idempotency keys, and the removal of CANC from VRP status values will show up as contract-test failures if your client was generated from the April 2026 YAML. 8. Verify SCA exemptions and VoP separately. Open banking payments are push payments, so the SCA exemption logic for cards does not apply, but from October 2025 every euro-area SEPA payment you initiate triggers a Verification of Payee check on the bank side, and the match result arrives before the SCA step.

The honest summary is that "PSD2 API" names a legal obligation, not an interface. I am Tom Wang, and after enough integrations I stopped expecting the standards to converge. Plan for three, and let the abstraction layer earn its keep.