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. Note that Sparebanken Norge is operating on two separate PSD2 interfaces until the technical merger of Sparebanken Vest and Sparebanken Sør is completed as planned in Q4 2026:

1. Sparebanken Norge (Sør) (former Sparebanken Sør) is operating on Tieto Evry Open Banking Portal https://openbanking.sor.no/developer/

2. Sparebanken Norge (former Sparebanken Vest) and Bulder Bank offers PSD2 services by use of PSD2 APIs https://developer.spvapi.no/documentation/psd2/ based on the Berlin Group NextGenPSD2 standard, as a dedicated PSD2 interface for all TPPs.

One common PSD2 interface is currently planned in Q4 2026. We will inform all TPPs well ahead of the technical merger into one common interface.

Sparebanken Norge and Bulder Bank’s dedicated interfaces (APIs) are continously being developed. We strive to provide interfaces that suits the use cases of all our TPPs, enabling good customer experiences for our common customers.

Please see TPP requirements for accessing APIs below.

Important notice to TPPs using our ordinary interfaces: During the early development of our PSD2 APIs in 2019-2020 as our dedicated PSD2 interface, some TPPs connected to our ordinary interfaces as the only (or primary) interface of their PSD2 services. We strongly advice all TPPs using our ordinary interfaces as the only (or primary) interface for their PSD2 services, to start the transition to our dedicated interface in our PSD2 APIs as the primary interface of their PSD2 services. Sparebanken Norge and Bulder Bank will offer PSD2 services by use of our PSD2 APIs as a dedicated PSD2 interface for all TPPs.

TPP Requirements for PSD2 APIs

In order to authenticate towards Sparebanken Norge and Bulder Banks 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 at our status page

Information about ongoing incidents, planned maintenance and change announcements will be published on our statuspage. 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 and each endpoint uses each bank’s respective SCA solution.

Endpoint for dedicated interface Sparebanken Norge: https://psd2.spvapi.no

Endpoint for dedicated interface Bulder Bank: https://psd2-bulder.spvapi.no

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:

• GET /v1/accounts is limited to

  • No more than 4 calls per 24-hour period
  • Accounts for which the PSU has given consent to access

• GET /v1/accounts/{accountId}/balances is limited to

  • No more than 4 calls per 24-hour period
  • Accounts for which the PSU has given consent to access

• GET /v1/accounts/{accountId}/transactions is limited to

  • No more than 4 calls per 24-hour period
  • Transactions no more than 90 days old

Payment Initiation Services (PIS)

These services allows 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 and each endpoint uses each bank’s respective SCA solution.

Endpoint for dedicated interface Sparebanken Norge: https://psd2.spvapi.no

Endpoint for dedicated interface Bulder Bank: https://psd2-bulder.spvapi.no

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 Codes Description

Payment Status Transitions

These are the status transitions that you most commonly will see, and which it makes sense to act upon as a TPP. Note that RJCT is not part of these flows as it can happen at any time before ACSC, and should thus be handled generally as an error.

Normal payment

In general, payments should be expected to follow this state flow.

Payment with instant completion

Some payments get completed instantly which means polling for status is irrelevant.

Payment with SCA Exemption

Payment without posting to creditor’s account

Payment with multiple signatures required

Periodic payment

Cancel Payment Before Payment Authorisation

Error Codes and Responses

The XS2A Framework Implementation Guidelines describes the error codes and responses that are used in the Berlin Group NextGenPSD2 standard. The error codes are described in detail in the Berlin Group NextGenPSD2 documentation. Those lists can be found below where “Message Code” is the value of the code field in the API response.

Service Unspecific Error Codes

Payment Initiation Service Specific HTTP Error Codes

Account Information Service Specific HTTP Error Codes

Signing Basket Specific HTTP Error Codes

Sandbox Environment for PSD2 APIs

A sandbox environment for the dedicated PSD2 interface is available. The sandbox environment has the same TPP requirements for use as our production environment. (At the moment we do not trust test QWACs) No sign-up or registration is needed. The Sandbox environment covers both Sparebanken Norge, and Bulder Banks API experience. It only provides a single sandbox SCA solution.

For more information about the sandbox environment check this Github repository.

Endpoint for sandbox interface: https://psd2-sandbox.spvapi.no

Details for Contingency Solution

Authentication when using our ordinary interfaces for PSD2 access to accounts

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

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

Requirements for TPPs using Sparebanken Norge’s fallback mechanism

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

SPV-PSD2-Fallback-TPP-Cert: Base64 encoded JWK Qseal certificate

The TPPs 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.

SPV-PSD2-Fallback-TPP-Qseal: TPP issued JWT

To prove possession of the Qseal certificate private key, a JSON Web Token (JWT) must be constructed. It 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)

The JWT must include the following header fields (kid/x5t are example values only):

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

The JWT must include the following claims:

• “iss”: The full name of the TPP, as registered in the Qseal certificate.
• “aud”: spv fallback prod for production use
• “exp”: Expiry must be set to no longer than one hour from the time the token was issued. (A new token should be created after one hour, if needed).
• “nbf”: Not before, should be set to the time of issuance.
• “iat”: Issued at, should be set to the time of issuance.
• “jti”: JWT ID - a 128-bit randomly generated ID.

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