2.9.114. Feb 2023Description of TPP-Session-ID updatedn/a
2.8.802. Nov 2021Updated sections on "User not Present" and SCA-
2.8.67. Dec 2020Updated references to BG implementation guidelines-

Future Breaking Change

This section describes breaking changes that can be enabled per request if the client already supports the described functionality.
The optional functionality is controlled using a HTTP header named x-accept-fix.
At some point in the future the functionality should be expected to be made default.

To support several fixes, comma-separate them in the x-accept-fix header, eg: x-accept-fix : "longer-names, amount-as-string"

  • Card-account: the value of transactionAmount and originalAmount will be switched during Q1 2021. To prepare for this, including "cardaccount-switch-originalamount-and-transactionamount" in the x-accept-fix header will enable the fix today. May not affect all card-providers.
  • Card-account and account name: the max length of the name field will be extended to 70 chars in Q1 2021. To prepare for this, including "longer-names" in the x-accept-fix header will enable this fix today.

Implemented Breaking Changes after 3 month Future Breaking Change period

  • Amounts are now serialized as string; "amount-as-string" x-accept-fix no longer needed/active

Known Issues

  • It is currently not possible to get the details or status of a payment initiation request for domestic-norway-credit-transfers before approving the payment.
  • Due to limitation in our backend systems, GET /v1/accounts/{id}/transactions with bookingStatus=both or pending will always return all pending transactions. dateFrom, dateTo and limit cannot be used to filter pending transactions. Sandbox and card-account services is not affected by this issue.


This document explains how you as a TPP should integrate with the Open Banking API. It describes what endpoints should be called in what order, how to sign requests and what data to send in different PSU contexts. Details on each endpoint can be found in the Developer Portal, or in the Berlin Group XS2A Framework Implementation Guidelines. The implementation guidelines should also be consulted for details on the request and response data structures of these endpoints. The API is with some notable exceptions that will be covered later in this document, based on version 1.3 of the implementation guidelines.

The system is split into two parts: The production environment, which has real PSU data. The sandbox environment, which is a safe test environment with fake user data.


  • Before attempting to use any API you need to fulfill the Prerequisites
  • First test your client against the sandbox environment which is available in the Developer Portal.
  • When in production the client must use the production environment.
  • AISPs should start by reading the Account Information API section
  • There is a quick start example in Java


  • Before you can use the Account Information API you must be a registered AISP.
  • You need to obtain an eIDAS certificate from a trusted CA.

Your eIDAS certificate will be validated and your TPP-registration will be checked against central registries when you make requests to the Production APIs.

Mock Data

See Sandbox API for Dynamic Mock Data for how to use the dynamic mock data api.

You can also find a sample script for populating the sandbox with mock data here:PSD2 Developer Sample Code


This section presents and discusses some of the basic concepts and features found by the Open Banking API

Open Banking Actors

Payment Service UserPSUPersonA natural or legal person making use of a payment service as a payee, payer or both (PSD2 Article 4(10)).
Payment Service ProviderPSPLegal EntityA legal entity (and some natural persons) that provide payment services as defined by PSD2 Article 4(11).
Account Servicing Payment Service ProviderASPSPLegal EntityAn ASPSP is a PSP that provides and maintains a payment account for a payment services user (PSD 2 Article 4(15).
Third Party ProviderTPPLegal EntityA party other than an ASPSP that provides payment related services. The term is not actually defined in PSD2, but is generally deemed to include all payment service providers that are 3rd parties (the ASPSP and the PSU to whom the account belongs being the first two parties).
Account Information Service ProviderAISPLegal EntityA TPP that provides Account Information Services. Again, PSD2 defines AISPs in Article 4(19) circularly as a PSP that provides account information services.

RESTful Principles

The Open Banking API adheres to RESTful API concepts where possible and sensible to do so. However, the priority is to have an API that is simple to understand and easy to use. In instances where following RESTful principles would be convoluted and complex, the principles have not been followed.

Accepted Data Encoding

The Open Banking API encodes all data as JSON. Different XML formats also mentioned in Berlin Group XS2A Framework Implementation Guidelines is not supported, but could be supported in the future.

Character Encoding

The API requests and responses must use a UTF-8 character encoding, as is the default for JSON text in [RFC 7158 - Section 8.1][53]. However, an ASPSP's downstream system may not accept some UTF-8 characters, such as emojis. If the ASPSP rejects the request with a message that a UTF-8 character cannot be processed, the ASPSP should respond with a 400 (Bad Request).

Date Formats

All dates in the JSON payloads are represented in ISO 8601 date or date time format.

ISO 8601 Date 2018-05-17

ISO 8601 DateTime 2018-05-17T08:37:12+00:00

All dates in the HTTP headers are represented as RFC 7231 Full Dates e.g. Sun, 17 May 2018 08:37:12 UTC

TPP Redirects

The TPP needs to implement some endpoints, so they can receive the query parameters in redirects from the ASPSP. Currently, the only redirects happens after the PSU has completed the SCA process. The URL for these redirects must always be provided by the TPP in the `TPP-Redirect-URI` header in case SCA is required.

Redirect after successful SCA process


Parameter NameTypeDescription
psu-idRFC 4122 UID (UUID)Identifies a PSU, it is unique for a given combination of TPP and ASPSP, and does not change. The value here should be provided in the `PSU-ID` header for all subsequent requests, and should be persisted by the TPP for future requests for the same PSU. The value of `PSU-ID` need not be shared with the PSU.
psu-corporate-id (optional)RFC 4122 UID (UUID)If the PSU chooses a corporate context this field will identify one corporate agreement belonging to the PSU (there could be multiple), and should be treated the same as the PSU-ID, but set to the `PSU-CORPORATE-ID` header instead.
tpp-session-idStringThe value of the `TPP-Session-ID` header used by the request that triggered the SCA process.
contextString, one of (PRIVATE, CORPORATE)indicates whether a PSU selected a `PRIVATE` or `CORPORATE` context. See corporate context

Redirect after failed SCA process


Parameter NametypeDescription
systemStringThe name of the internal system that produced the error in case of a server error
statusNumberHTTP status code
codeStringError code detailing the status
messageStringURL-encoded message, detailing the error

See Error Codes and Responses for details on error codes.

Security & Access Control

Transport Security

The communication between the TPP and the ASPSP is always secured by using a TLS-connection using TLS version 1.2 or higher.


Digital signatures as described by [draft-cavage-signatures-09][54] are used to facilitate non-repudiation for Open Banking API requests.

In addition digital signatures must adhere to requirements as described in XS2A Framework Implementation Guidelines, Section 11.

Signing Specification

The TPP must sign each API request.

The ASPSP should verify the signature of API requests it receives before carrying out the request. If the signature fails validation, the ASPSP must respond with a 400 (Bad Request).

The ASPSP must reject any API requests that should be signed but do not contain a signature in the HTTP header with a 400 (Bad Request).

The ASPSP may sign the HTTP body of each API response that it produces which has an HTTP body.

The TPP should verify the signature of API responses that it receives.

Signing Process

The process of signing HTTP messages is subject to change when the draft-cavage-http-signatures-09 and ETSI TS 119 495 standards release a final version of their specification.

The target url and the required header fields must be used to sign the request. The signature is contained in its entirety in the "Signature" header field.

The 4 parts of a signature header: |Name|Description| |----|-----------| |keyId |the id of the key used to sign the request (in case of rsa-sha256 this points to a RSA Private Key) | |algorithm | the algorithm used for signing (for example rsa-sha256) | |headers | contains all the required header names separated by space in the same order they will be concatenated for signing. | | target url | which is not a header is indicated with (request-target) | |signature | The signature string, see below |

Requirements for Key ID

It consists of two parts SN= and CA= SN should contain the hex encoded upper case representation of the serial number of the certificate. CA should contain The issuer of the certificate. This should be formatted according to RFC 2253.

*Required Headers for Signature** The headers listed below should be put in the signature if they are used in the request.

  • date
  • digest
  • x-request-id
  • psu-id
  • psu-corporate-id
  • tpp-redirect-uri

Signature Requirements: If a header is not included in the request it should not be included in the signature All header names must be lower case. Concatenate header names and values with a separator of ":" and a space. Separate each header with a newline Remember to use the same headers in the same ordering as the "headers" value Sign this string using the defined by algorithm and the key defined by keyId. * Base64 encode the resulting bytes.

Example of how to concatenate header fields before signing first-header-name: first-header-value second-header-name: second-header-value

After this concatenate the 4 parts of the signature header in order: Format each part: key="value" Concatenate each part using ',' (comma)

Example of a completed signature header

Assume the `algorithm` value was "rsa-sha256". This would signal to the application that the data associated with the `keyId` is an RSA Private Key, the signature string hashing function is SHA-256, and the signing algorithm is the one defined in Section 8.2.1 of [RFC 3447][55]. The result of the signature creation algorithm should result in a binary string, which is then base 64 encoded and placed into the `signature` value, currently indicated as "base64(rsa-sha256(signing-string))".

Signature: keyId="SN=DCC5CCB85FDAB32A,CA=O=PSDNO-FSA-SOMEASPSP,L=Trondheim,C=NO,CA=", algorithm="rsa-sha256", headers="digest tpp-transaction-id tpp-request-id psu-id date", signature="base64(rsa-sha256(signing-string))"

ISO-8859-1 or UTF-8 encoded headers

If any values in the signature header is ISO-8859-1 or UTF-8 encoded you need to URL encode the signature header according to RFC 2047 which means MIME encoding the signature.

Also the signature must be wrapped using this format: =?charset?encoding?encoded signature?=

Signature example with this encoding: Signature: =?utf-8?B?a2V5QTQsQ0E9Mi41LjQuOTc9IzB........jMTM1MDUzNDQ0ZTRmMmQ0NjUz?=

Java example of how to implement encoding: if (charset.equals(StandardCharsets.UTF_8)) { signature = String.format("=?utf-8?B?%s?=", Base64.getEncoder().encodeToString(signature.getBytes(StandardCharsets.UTF_8))); }

Strong Customer Authentication

SCA is mandated by the RTS and supported by the Open Banking API using the SCA redirect flow as detailed in XS2A Framework Implementation Guidelines, Section 5.1.
The message flow used is relatively simple and straight forward;

  • requests that require SCA will be responded to with a scaRedirect link to the ASPSP SCA authorization site
  • after the SCA process is complete the ASPSP will redirect the PSU to the URI provided by the TPP in the `TPP-Redirect-URI` header

Note that the `TPP-Redirect-URI` header is required for all requests, as the TPP has no prior knowledge of when a PSU will be required to complete the SCA process.
During the SCA process the ASPSP will automatically gather consent, and the TPP will for subsequent request only be granted access to interact with these consented accounts.
SCA is valid for a single TPP and PSU but across TPP roles (such as PISP and AISP) for one hour within a session, as governed by `TPP-Session-ID`. Such sessions must be managed in accordance with the PSD2 regulative.
Following a successful SCA process the PSU will be redirected to the `TPP-Redirect-URI` which should be a TPP endpoint as described in TPP Redirects


  • An SCA within a given TPP-Session-ID will last for up to 1 hour before expiring. The use of TPP-Session-ID will prevent the API from prompting for new SCA during the 1-hour time window, when calling PSD2 API services requiring SCA. The SCA exemption for this 1-hour window does not apply to services that require SCA with dynamic linking. This functionality, including time limits, is identical to the standard internet bank.
  • When expired, an SCA is required to renew it.
  • Creating a new `TPP-Session-ID` before an old one is expired will require a new SCA, and if completed will invalidate the old `TPP-Session-ID`. If the SCA is aborted, the old `TPP-Session-ID` will still be valid.

Sandbox and Production

  • The user interface in production is similar to the other ASPSP channels. If it is the first time a TPP asks for access to accounts the PSU must confirm granting access before selecting SCA method and performing SCA.
  • The user interface in the sandbox environment is simplified to allow for testing mocked PSUs. Only a mocked national identification number is required here.
  • The SCA flow as seen from a TPP is the same for both sandbox and production.


This API uses the Bank Offered Consent approach described in XS2A Framework Implementation Guidelines, section 6.4 It means that the PSU will give consent during the SCA redirect or directly with the ASPSP, and the POST to /v1/consents will disregard the body and only return a sca redirect.

Consents are granted by a PSU to a TPP for access to details, balances and transactions on accounts held with the ASPSP. This means that a TPP do not have access to any account information from a PSU until access has been explicitly granted.

The consent flow is explained further under Account Information API.

Bank Offered Consent User Interface

This is a description of the ASPSP user interface the PSU will see, and it does not directly affect the TPP. This flow is the same in sandbox and production.

  • When granting consent the PSU will first need to perform SCA as described under "Strong Customer Authentication".
  • Then it will be presented with a list of selectable accounts (checkbox list)
  • In case the PSU has already granted consent the accounts that the TPP has been given access to are already selected.
  • The PSU then deselects the accounts it wants to revoke consent for and selects the accounts it wants to grant consents for.
  • The PSU then confirms and gets redirected to the TPP.

Consent Revocation

A PSU can revoke consent for accessing account information at any point in time.

The PSU can revoke authorization directly with the ASPSP. The mechanisms for this are in the competitive space and are up to each ASPSP to implement in the ASPSP's banking interface. ASPSPs are under no obligation to notify TPPs regarding the revocation of authorisation.

Account Information API

This API allows TPPs to access the accounts of a PSU and see account numbers, balances and transactions. Every sandbox and production request must be signed, this means the request need to contain the header `Signature`, see Signing Process. Every request must have the header `TPP-Redirect-URI`. This should point to a endpoint in your application, the TPP Redirect Endpoint * The `TPP-Session-ID` is optional and can be used to correlate a redirect to the original request.

Below you will find detailed steps for doing your first request.

Quick Start Accounts Full Java Example

This is a full example showing how to get accounts. You need Java 11 for this example to work.

package your.package;

import okhttp3.Headers;
import okhttp3.OkHttpClient;
import okhttp3.Request;
import okhttp3.Response;

import org.bouncycastle.jce.provider.BouncyCastleProvider;

import java.lang.invoke.MethodHandles;
import java.nio.charset.StandardCharsets;
import java.nio.file.Files;
import java.nio.file.Path;
import java.time.ZonedDateTime;
import java.time.format.DateTimeFormatter;
import java.util.*;
import java.util.concurrent.TimeUnit;

 * Check the prerequisites before running this sample.
 * This code requires OkHttp and Bouncy castle as dependencies
 * Update variables with relevant values and run the main method to test.
 * Maven dependencies:
 *      org.bouncycastle
 *      bcprov-jdk15on
 *      1.61
 *  com.squareup.okhttp3
 *      okhttp
 *      3.13.1
public class Psd2DEMOClient {

    private static String[] signatureHeaders = {"date", "digest", "x-request-id", "psu-id", "psu-corporate-id", "tpp-redirect-uri"};

    public static void main(String[] args) throws Exception {
        OkHttpClient httpClient = createOkHttpClient();

        See the getAccount method description for information on the different fields and the sample values set here.
        String certificateFile = "cert.pem";
        String keyFile = "cert.pkcs8.key";

        set this to a constant value or change it to the tpp-session-id query parameter value after following the redirect.
        String tppSessionId = UUID.randomUUID().toString()+"-codesample";

        set this one after following the redirect and run it again
        String psuId = null;

        URL url = new URL("----- ASPSP BASE URL WITH TRAILING '/' ----");
        Request request =  Psd2DEMOClient.getAccounts(certificateFile, keyFile, url, tppSessionId, psuId);

        Response response = httpClient.newCall(request).execute();

        System.out.println("---------- Request ----------");

        System.out.println("---------- Response ----------");
        String body = response.body().string();


        if(body.contains("accounts")) System.out.println("Yay you got accounts!");
        else if(response.code() == 200) System.out.println("Yay! It seems like it worked, but no accounts were found.");
        else if(body.contains("scaRedirect")) System.out.println("Yay! you got through, now follow the scaRedirect link and then try again using the psu-id and tpp-session-id from the url parameters in the final redirect.");
        else System.out.println("Something went wrong! Check the response message for details.");

     * Make sure your certificate is registered with the ASPSP.
     * When this method has been executed successfully the body of the response (as a string) should contain a _link with a scaRedirect and a href.
     * 1. Open the url in your browser.
     * 2. Follow the SCA flow in the browser
     * 3. After final redirect you will see a set of query parameters in the url in your browser. (example:
     * 4. Use the PSU-ID and Tpp-session-id url parameter values for subsequent requests.
     * @param certificateFile path to the certificate pem file.
     * @param keyFile path to the certificate key file.
     * @param baseUrl ASPSP url with a trailing '/'(url to the sandbox environment excluding the path v1/accounts)
     * @param tppSessionId  any string (for example a UUID string) it identifies the session. The same id should be used for every request in a PSU session
     * @param psuId optional psu id, after
    public static Request getAccounts(String certificateFile, String keyFile, URL baseUrl, String tppSessionId, String psuId) throws Exception {

        Append the API path to the API base url
        URL url = new URL(baseUrl,"v1/accounts");

        Request id to identify the request across services. Store this id and its audit trail!
        String requestId = UUID.randomUUID().toString();

        Read the certificate
        X509Certificate certificate = (X509Certificate) CertificateFactory.getInstance("X.509").generateCertificate(new ByteArrayInputStream(readResourceFile(certificateFile)));

        Read the certificate key
        PrivateKey privateKey = KeyFactory.getInstance("RSA").generatePrivate(new PKCS8EncodedKeySpec(readResourceFile(keyFile)));
        System.out.println("Private Key > Format: " + privateKey.getFormat());
        System.out.println("Private Key > Algorithm: " + privateKey.getAlgorithm());

        Base 64 encode the certificate for use in the header
        String encodedCertificate = Base64.getEncoder().encodeToString(certificate.getEncoded());

        Create headers to use for both the signature and the http request
        Map headers = new LinkedHashMap(Map.of(
                "X-Request-ID", requestId,
                "TPP-Session-ID", tppSessionId,
                "TPP-Redirect-URI", "",
                "TPP-Signature-Certificate", encodedCertificate,
                "PSU-IP-Address", "" //Use an actual PSU ip address here!

        if(psuId != null) {
            headers.put("PSU-ID", psuId);

        Make all headers lower case.
        Map normalizedHeaders = headers
                .collect(Collectors.toMap(entry -> entry.getKey().toLowerCase(), Map.Entry::getValue));

        Create signature.
        String signature = createSignature(certificate, privateKey, normalizedHeaders);

        Create a request and set all headers including the signature header.
        Headers.Builder headerBuilder = new Headers.Builder();

        return new Request.Builder().url(url)
                .header("Signature", signature)


     * @param certificate Valid X509 certificate registered on a TPP
     * @param privateKey The Private key of the x509 certificate
     * @param requestHeaders
     * @return The signature
     * @throws Exception
     private static String createSignature(X509Certificate certificate, PrivateKey privateKey, Map requestHeaders) throws Exception {

         Certificate serial number on upper case hex form.

            Example output: 6AEB4444FBAAD267
        String upperCaseHEXSerialNumber = certificate.getSerialNumber().toString(16).toUpperCase().trim();

        Create the keyId value by Concatenating the serial and issuer name items using SN=***,CA=***
            (Note that "CA=" is not part of the issuer name and "SN=" is not part of the serial)

            Example output:
         String keyId = String.format("SN=%s,CA=%s",
         System.out.println("Signature > Key ID: "  + keyId);

        Filter the headers so only the ones needed for the request are left.
        List headersForSigning = requestHeaders.entrySet().stream()
                .filter(headerName -> Arrays.asList(signatureHeaders).contains(headerName))

        Create the headers value by concatenating the header names (Concatenate with whitespace *not* comma)

            This is used to communicate the header ordering to the ASPSP for signature validation.
        String headers = String.join(" ", headersForSigning);

        Concatenate all the headers to make the signing string.

            They are concatenate in this way:
                name1: value1
                name2: value2
        String signingString =
                .map( headerName -> String.format("%s: %s", headerName, requestHeaders.get(headerName)))

        Sign the string using RSA SHA256.

            The output is a byte array
        Signature sha256withRSA = Signature.getInstance("SHA256withRSA", new BouncyCastleProvider());
        byte[] signedBytes = sha256withRSA.sign();

        Validate signature (this is not strictly neccessary, the purpose in this example is to provide error messages
        if there is a problem with the input certificate or key).

        Base 64 encode the byte result of the signing algorithm to get a string.
        String base64EncodedSignedBytes = Base64.getEncoder().encodeToString(signedBytes);

         boolean valid = sha256withRSA.verify(signedBytes);
         if (valid) {
             System.out.println(String.format("Signature > VALID when checked against certificate with serial %s", upperCaseHEXSerialNumber));
         } else {
             System.out.println(String.format("Signature > NOT VALID when checked against certificate with serial %s", upperCaseHEXSerialNumber));
             throw new SignatureException(String.format("Signed bytes is signed using a private key not matching the certificate with serial %s", upperCaseHEXSerialNumber));

        Create the signature header value by concatenating the keyId value, headers value, algorithm used and the base 64 encoded signature.

            Example output: keyId="SN=6AEB4444FBAAD267,CA=O=PSDNO-FSA-ABCA,L=Trondheim,C=NO", algorithm="rsa-sha256", headers="date x-request-id tpp-redirect-uri psu-id", signature="***************"
        String signature = String.format("keyId=\"%s\",algorithm=\"rsa-sha256\",headers=\"%s\",signature=\"%s\"", keyId, headers, base64EncodedSignedBytes);

        return signature;

    private static OkHttpClient createOkHttpClient() {
        return new OkHttpClient.Builder()
                .connectTimeout(60 * 1000, TimeUnit.MILLISECONDS)
                .readTimeout(60 * 1000, TimeUnit.MILLISECONDS)
                .writeTimeout(60 * 1000, TimeUnit.MILLISECONDS)

    public static byte[] readResourceFile(String fileName) throws IOException {


        try (InputStream inputStream = MethodHandles.lookup().lookupClass().getResourceAsStream(fileName)) {
            return inputStream.readAllBytes();



To get access to account information you need to perform minimum these steps.

  1. Do a GET to /v1/accounts (or any other resource you want to access)
    • This will return a 401 Unauthorized data containing a scaRedirect link.
  2. Redirect the PSU using scaRedirect, or present the link in an iframe to start the SCA flow.
    • The PSU may now give consent to some or all of its accounts.
    • The PSU will then be validated against the ASPSP and consent will be registered directly in the SCA flow, completely hidden from the TPP.
    • After completing the SCA flow the PSU will be redirected to the url provided in the `TPP-Redirect-URI`
    • The redirect will contain a PSU-ID which must be used on consecutive calls to the API
  3. Persist the PSU-ID, it should be used in all future requests for this PSU.
  4. You may now call the same resource as in the first step again (GET /v1/accounts).
    • Remember to add the `PSU-ID` header using the psu-id you got in the redirect.
    • For GET /v1/accounts you will now get a list of all accounts the PSU has given consent to.

After these steps the other account resources can be accessed the same way as GET /v1/accounts in the last step, even after the user session ends (with some limits: Request Limits).

Sequence Diagram

Sequence diagram

User Not Present - Request Limits

The header `PSU-IP-Address` must be present if the PSU has asked for this account access in real-time.

`PSU-IP-Address` shall be the ip address of the device the PSU is using to access the TPP service.

If the TPP want to make a request without a PSU present, the `PSU-IP-Address` shall not be set.

There are two cases where a TPP can make requests without the `PSU-IP-Address`, and that does not generally require SCA.

However, some restrictions apply:

  • GET /v1/accounts/{id}/balances is limited to
    • No more than 4 calls per 24-hour period
    • Accounts for which the PSU has granted consent
  • GET /v1/accounts/{id}/transactions is limited to
    • No more than 4 calls per 24-hour period
    • Transactions that are no more than 90 days old
    • Accounts which the PSU has accessed online, triggering an SCA within the last 90 days

Error Codes and Responses

XS2A Framework Implementation Guidelines, Section 14.11 defines the possible error codes. Those lists can be found below where "Message Code" will appear in the "code" field of a error response.

Service Unspecific Error Codes

Message CodeHTTP Response CodeDescription
CERTIFICATE_INVALID401The contents of the signature/corporate seal certificate are not matching PSD2 general PSD2 or attribute requirements.
ROLE_INVALID401The TPP does not have the correct PSD2 role to access this service.
CERTIFICATE_EXPIRED401Signature/corporate seal certificate is expired.
CERTIFICATE_BLOCKED401Signature/corporate seal certificate has been blocked by the ASPSP or the related NCA.
CERTIFICATE_REVOKED401Signature/corporate seal certificate has been revoked by QSTP.
CERTIFICATE_MISSING401Signature/corporate seal certificate was not available in the request but is mandated for the corresponding.
SIGNATURE_INVALID401Application layer eIDAS Signature for TPP authentication is not correct.
SIGNATURE_MISSING401Application layer eIDAS Signature for TPP authentication is mandated by the ASPSP but is missing.
FORMAT_ERROR400Format of certain request fields are not matching the XS2A requirements. An explicit path to the corresponding field might be added in the return message. This applies to headers and body entries. It also applies in cases where these entries are referring to erroneous or not existing data instances, e.g. a malformed IBAN.
PARAMETER_NOT_CONSISTENT400Parameters submitted by TPP are not consistent. This applies only for query parameters.
PARAMETER_NOT_SUPPORTED400The parameter is not supported by the API provider. This code should only be used for parameters that are described as "optional if supported by API provider."
PSU_CREDENTIALS_INVALID401The PSU-ID cannot be matched by the addressed ASPSP or is blocked, or a password resp. OTP was not correct. Additional information might be added.
SERVICE_INVALID400 (if payload) or 405 (if HTTP method)The addressed service is not valid for the addressed resources or the submitted data.
SERVICE_BLOCKED403This service is not reachable for the addressed PSU due to a channel independent blocking by the ASPSP. Additional information might be given by the ASPSP.
CORPORATE_ID_INVALID401The PSU-Corporate-ID cannot be matched by the addressed ASPSP.
CONSENT_UNKNOWN403 (if path) or 400 (if payload)The Consent-ID cannot be matched by the ASPSP relative to the TPP.
CONSENT_INVALID401The consent was created by this TPP but is not valid for the addressed service/resource.
CONSENT_EXPIRED401The consent was created by this TPP but has expired and needs to be renewed.
RESOURCE_UNKNOWN404 (if account-id in path), 403 (if other resource in path) or 400 (if payload)The addressed resource is unknown relative to the TPP. An example for a payload reference is creating a signing basket with an unknown resource identification.
RESOURCE_EXPIRED403 (if path) or 400 (if payload)The addressed resource is associated with the TPP but has expired, not addressable anymore.
RESOURCE_BLOCKED400The addressed resource is not addressable by this request, since it is blocked e.g. by a grouping in a signing basket.
TIMESTAMP_INVALID400Timestamp not in accepted time period.
PERIOD_INVALID400Requested time period out of bound.
SCA_METHOD_UNKNOWN400Addressed SCA method in the Authentication Method Select Request is unknown or cannot be matched by the ASPSP with the PSU.
STATUS_INVALID409The addressed resource does not allow additional authorisation.

Account Information Service Specific HTTP Error Codes

Message CodeHTTP Response CodeDescription
CONSENT_INVALID401The consent definition is not complete or invalid. In case of being not complete, the bank is not supporting a completion of the consent towards the PSU. Additional information will be provided.
SESSIONS_NOT_SUPPORTED400The combined service flag may not be used with this ASPSP.
ACCESS_EXCEEDED429The access on the account has been exceeding the consented multiplicity without PSU involvement per day.
REQUESTED_FORMATS_INVALID406The requested formats in the Accept header entry are not matching the formats offered by the ASPSP.

Sandbox API for Dynamic Mock Data


You can find a sample script for populating the sandbox with mock data here: PSD2 Developer Sample Code

Note: delete operations are cascading which means if you delete a user all agreements and accounts for that user also gets deleted.

The sandbox api is used to populate the sandbox environment with test data.

This makes it easy to test the API with predictable data tailored to the edge cases in your application.

There are mainly two parts to the Sandbox API: Managing users and roles Managing accounts and transactions

Users and Roles

To access the data of a customer customerNumber is used during the SCA flow.

Private Users

  • To create a private user simply perform a POST to /v1/sandbox/customers.
  • An agreement is created automatically for you, and accounts added to this customer will automatically be added to that agreement.
  • You can see the agreement by calling GET /v1/sandbox/agreements.

Accounts and Card Accounts

  • Accounts and Card Accounts are managed with using POST,GET and DELETE /v1/sandbox/accounts and POST,GET and DELETE /v1/sandbox/card-accounts.
  • Accounts and Card Accounts also has transactions which are managed with POST,GET and DELETE /v1/sandbox/accounts/{id}/transactions and POST,GET and DELETE /v1/sandbox/card-accounts/{id}/transactions.
  • Account owner should as previously mentioned be the PSU customer.
  • Accounts are linked to users via agreements and engagements.

Testing Payment functionality

  • Payments can be tested by performing payments to and from mock accounts in the sandbox API, like in production.
  • Payments will show up as transactions on the mock account when they are approved.
  • Payments will also change the balance of a mock account.


  • NextGenPSD2 Framework - Operational Rules, The Berlin Group Joint Initiative on a PSD2 Compliant XS2A Interface, version 1.0, published 08 February 2018
  • NextGenPSD2 Framework - Implementation Guidelines, The Berlin Group Joint Initiative on a PSD2 Compliant XS2A Interface, version 1.3 published 19 October 2018
  • Signing HTTP Messages
  • Instance Digest in HTTP


Javascript Request Signing Code Sample

const crypto = require('crypto'); //

function sign(key, headers) {
  var headerStrings = Object.keys(headers).map(function(header) {
    return header.toLowerCase() + ": " + headers[header];

  var signature = crypto.createSign('RSA-SHA256');
  return signature.sign(key, 'base64');

function format(parameters) {
  var supportedParameters = ['keyId', 'algorithm', 'headers', 'signature'];
  var parameterStrings = {
    return parameters[param] ? param + '="' + parameters[param] + '"' :
  return parameterStrings.join(",");

createSignature = function(certificate, headers) {
  const signingHeaders = ['date', 'digest', 'x-request-id', 'psu-id', 'psucorporate-
  id', 'tpp-redirect-uri'];
  const headerCopy = {};
  Object.keys(headers).forEach(function(key) {
    if (signingHeaders.indexOf(key.toLocaleLowerCase()) > -1) {
      headerCopy[key] = headers[key];
  try {
    const signature = sign(certificate.key, headerCopy);
    return format({
      keyId: certificate.issuer,
      algorithm: certificate.algorithm,
      headers: Object.keys(headerCopy).join(' '),
      signature: signature
  } catch (e) {
    console.log('failed to create signature', e);
    return null;

createDigest = function(body) {
  if (body) {
    const digest = crypto.createHash('sha256').update(body,
    return 'SHA-256=' + digest;
  } else {
    return null;

main = function() {
  certificate = { // No blank spaces in the key
    // key: content of key.der file that starts with -----BEGIN PRIVATE
    KEY----- and end with -----END PRIVATE KEY-----
    key=`-----BEGIN PRIVATE KEY-----
    private key content
    -----END PRIVATE KEY-----
    issuer: 'SN=D9ED5432AA92D251,CA=O=PSDNO-FSASOMENAME,
    algorithm: 'rsa-sha256'
  htmlBody = "{someJsonContent: 1234}"; // content of body that is sent
  in POST requests
  headers = {
    digest: createDigest(JSON.stringify(htmlBody)),
    'x-request-id': '1234567',
    'psu-id': 'some-id',
    'tpp-redirect-uri': '',
    date: 'Fri, 25 Jan 2019 13:42:20 GMT'
  const signature = createSignature(certificate, headers);