PSD2

🌍 Overview

Sparebanken Norge and Bulder Bank offers PSD2 services by use of our PSD2 APIs based on the Berlin Group NextGenPSD2 standard, as a dedicated PSD2 interface for all TPPs. The interfaces (APIs) are continuously being developed. We strive to provide interfaces that suit the use cases of all our TPPs, enabling good customer experiences for our common customers.

Note: Sparebanken Norge is operating on three separate PSD2 interfaces until the technical merger of Sparebanken Vest, Sparebanken Sør and Oslofjord Sparebank is completed:

1. Sparebanken Norge (former Sparebanken Vest) and Bulder Bank — own PSD2 APIs at https://developer.spvapi.no/documentation/psd2/ (continuing interface)
2. Sparebanken Norge (Sør) [former Sparebanken Sør] — Tietoevry Open Banking Portal at https://openbanking.sor.no/developer/ (until Q4 2026)
3. Sparebanken Norge (Oslofjord) [former Oslofjord Sparebank] — Tietoevry Open Banking Portal at https://psd2.oslofjordsparebank.no/developer/ (until Q1 2027)

Sparebanken Norge (former Sparebanken Vest) PSD2 APIs is the surviving / continuing interface. We will inform all TPPs 3 months ahead of each technical merger, as we will be phasing out an interface.

🔐 TPP Requirements for PSD2 APIs

In order to authenticate towards Sparebanken Norge and Bulder Bank’s PSD2 APIs in production, the TPP must:

• Be in possession of one or more valid, qualified QWAC eIDAS certificates in accordance with ETSI TS 119 495
• Use a QWAC certificate to establish mutually authenticated TLS connections (mTLS)
• Support at least TLS 1.2, and strong cipher suites (subject to continuous change)

📢 Subscribe to Updates

Information about ongoing incidents, planned maintenance and change announcements will be published on our status page. We recommend that you subscribe to these updates to stay informed.

🏦 Account Information Services (AIS)

With these services you will be able to retrieve balances and transactions from your end users’ account. Read about our account information services here.

The difference between the two endpoints is mainly the SCA solution — each endpoint uses each bank’s respective SCA solution.

Request Limits

The header PSU-IP-Address must be present when a PSU is requesting information. PSU-IP-Address shall be the IP address of the device used by the PSU to access the TPP service. If the TPP wants to make a request without a PSU present, the PSU-IP-Address header shall not be set.

There are cases where a TPP can make requests without the PSU-IP-Address that does not generally require SCA. However, some restrictions apply:

💸 Payment Initiation Services (PIS)

These services allow end users to initiate payments from their accounts at Sparebanken Norge. The service will ask for a strong customer authentication as long as no exemption is applied. Read about our payment initiation services here.

The difference between the two endpoints is mainly the SCA solution — each endpoint uses each bank’s respective SCA solution.

Status Codes

Non-final payment status codes are updated asynchronously, which is why you need to poll for status updates after payment user approval. Different payment products have different statuses, and SCA exemptions may result in instantly completed payments. See XS2A Framework Implementation Guidelines, Sections 14.12 and 14.13 for details on the payment statuses.

Status Code Reference

Payment Status Transitions

These are the status transitions you will most commonly see. Note that RJCT is not part of these flows as it can happen at any time before ACSC and should be handled generally as an error.

Normal Payment

Instant Completion

SCA Exemption

Without Posting to Creditor’s Account

Multiple Signatures Required

Periodic Payment

Cancel Payment Before Authorisation

⚠️ Error Codes and Responses

The XS2A Framework Implementation Guidelines describes the error codes and responses used in the Berlin Group NextGenPSD2 standard. The error codes are described in detail in the Berlin Group NextGenPSD2 documentation. The code field in the API response corresponds to the “Message Code” below.

Service Unspecific Error Codes

Payment Initiation Service Error Codes

Account Information Service Error Codes

Signing Basket Error Codes

🧪 Sandbox Environment

A sandbox environment for the dedicated PSD2 interface is available. The sandbox environment has the same TPP requirements as production. No sign-up or registration is needed. The sandbox covers both Sparebanken Norge and Bulder Bank’s API experience with a single sandbox SCA solution.

Note: At the moment we do not trust test QWACs.

For more information, see the PSD2 Sandbox Documentation on GitHub.

🔄 Contingency / Fallback Solution

Authentication for PSD2 Access via Ordinary Interfaces

Third Party Providers (TPPs) must authenticate themselves before accessing the Payment Service User’s (PSU’s) online banking data. There is no “natural” approach to this in traditional user-centric online banking websites, so a more untraditional authentication approach is required.

This access will also serve as our fallback solution until we are exempted from having a fallback.

Requirements for TPPs Using the Fallback Mechanism

For every HTTP request made to Sparebanken Norge, the following two request headers must be included:

1. SPV-PSD2-Fallback-TPP-Cert

Base64-encoded JWK containing the QSeal certificate

The TPP’s QSeal certificate (including intermediates) must be presented in the JSON Web Key (JWK) format, using the x5c (X.509 Certificate Chain) parameter — see RFC 7517, Section 4.7. The JWK should be UTF-8 encoded and then Base64-encoded for inclusion in the HTTP header.

2. SPV-PSD2-Fallback-TPP-Qseal

TPP-issued JWT proving possession of the QSeal private key

The JWT must be signed with the QSeal private key using one of the following algorithms (see RFC 7518, Section 3.1):

• RS256 — RSASSA-PKCS1-v1_5 using SHA-256
• ES256 — ECDSA using P-256 and SHA-256

JWT Header (kid/x5t are example values only):

{
  "alg": "RS256",
  "kid": "E7B3AE9190916FDB58091EEE5FA7A55B56A736B3",
  "x5t": "57OukZCRb9tYCR7uX6elW1anNrM",
  "typ": "JWT"
}

JWT Claims:

Inclusion of both headers enables us to verify that the TPP has a valid QSeal certificate and controls its private key.