Open Banking API 1.0

Version Date Comment
1.0.0 2 May 2018 First version
1.1.0 7. March 2019 Simplified and added sample code
1.1.1 11. March 2019 Added sandbox users
1.2.0 03. May 2019 Adapted to Accounts
1.2.2 3. Jun 2019 Removed broken links
2.0.0 22. Aug 2019 Signature Logic Changed and updated Examples
2.1.0 13. Sep 2019 Known issue fixed
2.2.0 3. Okt 2019 Added Sandbox Mock Data Description
2.3.0 16. Okt 2019 Added Sandbox sample code repo link
2.3.1 24. Okt 2019 Fixed broken link
2.4.0 15. nov 2019 Adeed details on authorisations and consent handling
2.5.0 11. feb 2020 Updated with errors

Deprecation Warnings


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



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

Actor Abbreviation Type Description
Payment Service User PSU Person A natural or legal person making use of a payment service as a payee, payer or both (PSD2 Article 4(10))
Payment Service Provider PSP Legal Entity A legal entity (and some natural persons) that provide payment services as defined by PSD2 Article 4(11)
Account Servicing Payment Service Provider ASPSP Legal Entity An ASPSP is a PSP that provides and maintains a payment account for a payment services user (PSD 2 Article 4(15).
Third Party Provider TPP Legal Entity A 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 Provider AISP Legal Entity A 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


ISO 8601 DateTime


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 Name Type Description
psu-id RFC 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-id String The value of the `TPP-Session-ID` header used by the request that triggered the SCA process.
context String, one of (PRIVATE, CORPORATE) indicates whether a PSU selected a `PRIVATE` or `CORPORATE` context. See corporate context

Redirect after failed SCA process

Parameter Name type Description
system String The name of the internal system that produced the error in case of a server error
status Number HTTP status code
code String Error code detailing the status
message String URL-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.

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;

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 accross 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

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.

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.

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:
 *  <dependency>
 *      <groupId>org.bouncycastle</groupId>
 *      <artifactId>bcprov-jdk15on</artifactId>
 *      <version>1.61</version>
 *  </dependency>
 *  <dependency>
 *  <groupId>com.squareup.okhttp3</groupId>
 *      <artifactId>okhttp</artifactId>
 *      <version>3.13.1</version>
 *  </dependency>
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<String, String> headers = new LinkedHashMap<String, String>(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<String, String> 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<String, String> 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<String> 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)
  2. Redirect the PSU using scaRedirect, or present the link in an iframe to start the SCA flow.
  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).

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
Sequence diagram

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` should be the ip address of the device the PSU is using to access the TPP service.

When the TPP want to do a request without a PSU present it must omit `PSU-IP-Address`.

There are only two cases where a TPP can make requests and omit the `PSU-IP-Address`, and they have some restrictions:

Error Codes and Responses

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 Code HTTP Response Code Description
CERTIFICATE_INVALID 401 The contents of the signature/corporate seal certificate are not matching PSD2 general PSD2 or attribute requirements.
ROLE_INVALID 401 The TPP does not have the correct PSD2 role to access this service.
CERTIFICATE_EXPIRED 401 Signature/corporate seal certificate is expired.
CERTIFICATE_BLOCKED 401 Signature/corporate seal certificate has been blocked by the ASPSP or the related NCA.
CERTIFICATE_REVOKED 401 Signature/corporate seal certificate has been revoked by QSTP.
CERTIFICATE_MISSING 401 Signature/corporate seal certificate was not available in the request but is mandated for the corresponding.
SIGNATURE_INVALID 401 Application layer eIDAS Signature for TPP authentication is not correct.
SIGNATURE_MISSING 401 Application layer eIDAS Signature for TPP authentication is mandated by the ASPSP but is missing.
FORMAT_ERROR 400 Format 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_CONSISTENT 400 Parameters submitted by TPP are not consistent. This applies only for query parameters.
PARAMETER_NOT_SUPPORTED 400 The 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_INVALID 401 The 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_INVALID 400 (if payload) or 405 (if HTTP method) The addressed service is not valid for the addressed resources or the submitted data.
SERVICE_BLOCKED 403 This 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_INVALID 401 The PSU-Corporate-ID cannot be matched by the addressed ASPSP.
CONSENT_UNKNOWN 403 (if path) or 400 (if payload) The Consent-ID cannot be matched by the ASPSP relative to the TPP.
CONSENT_INVALID 401 The consent was created by this TPP but is not valid for the addressed service/resource.
CONSENT_EXPIRED 401 The consent was created by this TPP but has expired and needs to be renewed.
RESOURCE_UNKNOWN 404 (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 identficiation.
RESOURCE_EXPIRED 403 (if path) or 400 (if payload) The addressed resource is associated with the TPP but has expired, not addressable anymore.
RESOURCE_BLOCKED 400 The addressed resource is not addressable by this request, since it is blocked e.g. by a grouping in a signing basket.
TIMESTAMP_INVALID 400 Timestamp not in accepted time period.
PERIOD_INVALID 400 Requested time period out of bound.
SCA_METHOD_UNKNOWN 400 Addressed SCA method in the Authentication Method Select Request is unknown or cannot be matched by the ASPSP with the PSU.
STATUS_INVALID 409 The addressed resource does not allow addtitional authorisation.

Acccount Information Service Specific HTTP Error Codes

Message Code HTTP Response Code Description
CONSENT_INVALID 401 The 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_SUPPORTED 400 The combined service flag may not be used with this ASPSP.
ACCESS_EXCEEDED 429 The access on the account has been exceeding the consented multiplicity without PSU involvement per day.
REQUESTED_FORMATS_INVALID 406 The 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

Accounts and Card Accounts

Testing Payment functionality



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);