PSD2

Overview

Sparebanken Vest 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.

At the moment, Sparebanken Vest and Bulder Bank’s dedicated interfaces (APIs) are under continued development. Please see TPP requirements for accessing APIs below. We want to provide interfaces that suits the use cases of the third parties well, and enables the creation good customer experiences for our common customers.

We have not yet applied for an exemption of the obligation to set up our ordinary interfaces as a contingency mechanism under the PSD2 regulation, and our ordinary interfaces are available for third parties to access the accounts if the level of availability and performance of our dedicated interface (PSD2 APIs) temporarily does not comply with the PSD2 regulation. Follow this link for information on how to connect and identify your third party application to the bank using our ordinary interfaces as a fall back mechanism (described as “Contingency Solution” 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 Vest 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 Vest 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)

Payment initiation services (PIS)

These services will allow you to let your end user initiate a payment from their account at Sparebanken Vest. 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 Vest: https://psd2.spvapi.no

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

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 Vest: https://psd2.spvapi.no

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

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 Vest, 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 Vest’s (SPVs) fallback mechanism

For every HTTP request made to SPV, 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.