Skip to main content
Danske Bank logo
PSD2

Events - PSD2

Version

FSA NOTE

Introduction

This page contains documentation of Danske Bank's Openbanking UK and PSD2 apis.

Danske Bank provides the following sets of apis:

  • Openbanking APIs - apis for customers in UK, implementation of UK regulations. Requires a network+signing certificate issued by Openbanking UK Directory or a QWAC+QSEAL issued by a QTSP.

  • PSD2 APIs - apis for customers in Denmark, Finland, Ireland, Norway, Poland, Sweden, implementation of PSD2 directive. Requires a QWAC+QSEAL issued by a QTSP.

  • Sandbox APIs - testing facilities for Openbanking and PSD2 apis. Requires a network+signing certificate issued by Openbanking UK Directory or a QWAC+QSEAL issued by a QTSP. Test certificates issued by Microsec are also accepted.

All apis are based on Open Banking UK standards described here: link. Where necessary the apis were enhanced to support other EU countries.

The api technical specification can be found in the Reference section.

The api urls for Production and Sandbox testing facilities are described in the Endpoints section.

Other sections describe how to get access to the api (Onboarding), get an access token (Authorization) and call the apis.

Basic terminology:

A network certificate is an x509 certificate that will be used for providing mutual TLS between Danske Bank and the party invoking its apis.

A signing certificate is an x509 certificate that will be used for digitally signing content sent to Open Banking apis.

TPP means a Third Party Provider. TPP is any person / company that wants to integrate with Open Banking apis and provide a solution based on them. The identity of the provider needs to be well established. That’s why the network and signing certificates can be issued only by qualified providers who are able to confirm TPPs identity (and good intentions).

PSU means Payment Service User. In most cases PSU refers to a bank customer that uses solutions prepared by TPPs and gives permission to access to his resources via Open Banking apis. For example it might be a confirmation of a payment or approval to access his account history to provide some analytic insights.

Endpoints

Openbanking Production Endpoints

All Openbanking production endpoints have this base url: https://obp-api.danskebank.com/open-banking/

Important note: the TLS certificate used for this url is signed by Openbanking UK which is not a publicly recognized CA. The api version is appended to the url. A sample api url might look like this: https://obp-api.danskebank.com/open-banking/v4.0/aisp/account-access-consents

Details about each api can be found in the reference section. The OAuth2 authorization endpoints for Production are separate for business and private customers: https://obp-api.danskebank.com/open-banking/private/.well-known/openid-configuration https://obp-api.danskebank.com/open-banking/business/.well-known/openid-configuration

The Openbanking UK Directory well-known config can be found here: link.

Currently there is 1 onboarding endpoint – for TPPs with OB UK Directory certificates. https://obp-api.danskebank.com/open-banking/v1.0/thirdparty/register

More details on onboarding are in the Onboarding section.

PSD2 Production Endpoints

All PSD2 production endpoints have this base url: https://psd2-api.danskebank.com/psd2/ The api version is appended to the url. A sample api url might look like this: https://psd2-api.danskebank.com/psd2/v4.0/aisp/accounts/123 Details about each api can be found in the reference section. Note that consent creation endpoints will have an additional query parameter - country code . E.g. https://psd2-api.danskebank.com/psd2/v4.0/aisp/{countryCode}/account-access-consents The country codes supported by Danske Bank are: de, dk, fi, gb, ie, lu, no, pl, se. The OAuth2 authorization endpoints for Production are separate for each country code and business and private customers: https://psd2-api.danskebank.com/psd2/{countryCode}/{channel}/.well-known/openid-configuration E.g. https://psd2-api.danskebank.com/psd2/dk/private/.well-known/openid-configuration

Currently there is 1 onboarding endpoint – for TPPs with Eidas certificates. https://psd2-api.danskebank.com/psd2/v1.0/thirdparty/register

More details on onboarding are in the Onboarding section.

Sandbox Endpoints

All sandbox endpoints have this base url: https://sandbox-obp-api.danskebank.com/sandbox-open-banking/

The api version is appended to the url. A sample api url might look like this: https://sandbox-obp-api.danskebank.com/sandbox-open-banking/v4.0/aisp/account-access-consents

Details about each api can be found in the reference section. The OAuth2 authorization endpoints for Sandbox are separate for business and private customers: https://sandbox-obp-api.danskebank.com/sandbox-open-banking/private/.well-known/openid-configuration https://sandbox-obp-api.danskebank.com/sandbox-open-banking/business/.well-known/openid-configuration

Because the Sandbox authentication process is simplified on Sandbox there are no differences between private / business authorization flows. The Sandbox apis act as PSD2 and Openbanking UK testing facilities: https://sandbox-obp-api.danskebank.com/sandbox-open-banking/v1.0/thirdparty/register

More details on onboarding are in the Onboarding section.

Onboarding Overview

Onboarding to Sandbox is a 2 step process as shown on the sequence diagram below.

img2

Step 1. Obtain network and signing certs

To get access to Danske Bank’s apis you first need to obtain network and signing certificates from the qualified providers. For Openbanking UK apis you need to register with the Openbanking Directory and provide the necessary details using the UI (link). For PSD2 apis you need to acquire eIDAS certificates from a QTSP (link)

Next paragraphs describe each variant in more detail.

Step 2. Register in Danske Bank

Once the TPP acquires the network and signing certificate it needs to register with Danske Bank. Danske Bank implements ‘dynamic TPP registration’ method via a dedicated api. The result of TPP registration are client credentials (clientId, clientSecret). These can be used by TPP for authentication in OAuth2 flows as described later in this documentation. The registration looks different for Open Banking Directory and eIDAS issued certificates.

Onboarding with OB UK Directory

Step 1. Obtain OB network and signing certs

Open Banking Directory is an UK based solution that allows TPPs to register themselves as trusted entities and get the necessary resources to start using Open Banking apis from UK providers.

More information on the directory can be found here: https://www.openbanking.org.uk/providers/directory/

To start using Danske Bank’s Sandbox you need to enrol in the ‘Sandbox Directory’ (it’s a separate instance for testing purposes). An enrolling tutorial is available here: link. Open Banking Directory UK uses the OpenID Connect Registration standard (link). It requires from TPPs to submit a Software Statement (SSA) containing details about the TPP e.g. redirect uris, uri to jwks with the public certificates of TPP etc. Apart from this Open Banking Directory also acts as a CA. For more details please look in the Open Banking directory documentation. It is also possible to attach existing eIDAS certificates to a profile in the Open Banking directory.

Step 2. Register OB certs in Danske Bank

TPPs that have OB Directory issued certificates are registered using the OAuth2 Dynamic Client Registration flow (rfc7591). Additional information about this method is provided on Openbanking UK confluence: link. The Production TPP registration endpoint is: https://obp-api.danskebank.com/open-banking/v1.0/thirdparty/register The Sandbox TPP registration endpoint is: https://sandbox-obp-api.danskebank.com/sandbox-open-banking/v1.0/thirdparty/register

Payload for this service is a registration JWT signed with TPPs signing certificate. A sample decoded payload might look like this:

{
  "alg": "RS256",
  "kid": "Sd7MLsRmwyzyCMSmWwHr9XcIHzE",
  "typ": "JWT"
}.{
  "iss": "0015800000jf7AeAAI",
  "sub": "6cxMIpqLDWg0Dn3OPd6lH2",
  "redirect_uris": [
    "https://syst.obp-web.danskebank.com/open-banking/authorization-server/ui/authorize/business"
  ],
  "aud": "https://auth.danskebank.com",
  "scope": "openid accounts payments",
  "jti": "e0a3c4eb-6c6a-4607-b8bb-062e98d027db",
  "iat": 1548140027,
  "exp": 1548143627,
  "software_statement": "eyJhbGciOiJSU...",
  "client_id": "6cxMIpqLDWg0Dn3OPd6lH2",
  "id_token_signed_response_alg": "RS256",
  "request_object_signing_alg": "RS256",
  "token_endpoint_auth_method": "client_secret_post",
  "grant_types": [
    "authorization_code",
    "refresh_token",
    "client_credentials"
  ],
  "response_types": [
    "code",
    "code id_token"
  ],
  "application_type": "web"
}.{...}

The software statement attribute contains a software statement JWT signed by Open Banking. The statement can be acquired from Open Banking directory. A sample decoded software statement might look like this:

{
  "alg": "RS256",
  "kid": "dS3HEzsyVJOLzQVHIUkOJE2Iqkm3yHb4BY_PbBETWjY=",
  "typ": "JWT"
}.{
  "iat": 1548139987,
  "iss": "OpenBanking Ltd",
  "jti": "59RaMIcAcmgOtA7O2MZlQ8",
  "org_contacts": [
    {
      "email": "SCOT@DANSKEBANK.CO.UK",
      "name": "Business",
      "phone": "+442890048124",
      "type": "Business"
    },
    {
      "email": "AUPL@DANSKEBANK.LT",
      "name": "Technical",
      "phone": "+37060610977",
      "type": "Technical"
    }
  ],
  "org_id": "0015800000jf7AeAAI",
  "org_jwks_endpoint": "https://keystore.openbankingtest.org.uk/0015800000jf7AeAAI/0015800000jf7AeAAI.jwks",
  "org_jwks_revoked_endpoint": "https://keystore.openbankingtest.org.uk/0015800000jf7AeAAI/revoked/0015800000jf7AeAAI.jwks",
  "org_name": "Northern Bank Limited t/a Danske Bank",
  "org_status": "Active",
  "organisation_competent_authority_claims": {
    "authorisations": [
      {
        "member_state": "GB",
        "roles": [
          "AISP",
          "PISP"
        ]
      },
      {
        "member_state": "IE",
        "roles": [
          "AISP",
          "PISP"
        ]
      },
      {
        "member_state": "NL",
        "roles": [
          "AISP",
          "PISP"
        ]
      }
    ],
    "authority_id": "FCAGBR",
    "registration_id": "122261",
    "status": "Active"
  },
  "software_client_description": "SYST - Danske Bank TPP",
  "software_client_id": "6cxMIpqLDWg0Dn3OPd6lH2",
  "software_client_name": "SYST - Danske Bank TPP",
  "software_client_uri": "https://danskebank.co.uk",
  "software_environment": "sandbox",
  "software_id": "6cxMIpqLDWg0Dn3OPd6lH2",
  "software_jwks_endpoint": "https://keystore.openbankingtest.org.uk/0015800000jf7AeAAI/6cxMIpqLDWg0Dn3OPd6lH2.jwks",
  "software_jwks_revoked_endpoint": "https://keystore.openbankingtest.org.uk/0015800000jf7AeAAI/revoked/6cxMIpqLDWg0Dn3OPd6lH2.jwks",
  "software_logo_uri": "https://danskebank.com/-/media/danske-bank/dotcom/logos/danske-bank-logo.svg",
  "software_mode": "Live",
  "software_on_behalf_of_org": "",
  "software_policy_uri": "https://danskebank.com/openbanking",
  "software_redirect_uris": [
    "https://syst.obp-web.danskebank.com/open-banking/authorization-server/ui/authorize/business",
    "https://127.0.0.1"
  ],
  "software_roles": [
    "AISP",
    "PISP"
  ],
  "software_tos_uri": "https://danskebank.com/openbanking",
  "software_version": 1
}

Note that the public keys in the form of jwks are hosted by Open Banking.

A sample response from thirdparty/register endpoint might look like this:

HTTP/1.1 201 Created
Content-Type: application/json

{
	"client_id": "6cxMIpqLDWg0Dn3OPd6lH2",
	"client_secret": "...",
	"client_id_issued_at": 2893256800,
	"client_secret_expires_at": 2893276800,
	"redirect_uris": [
		"https://syst.obp-web.danskebank.com/open-banking/authorization-server/ui/authorize/business",
		"https://127.0.0.1"
	],
	"grant_types": ["authorization_code","refresh_token","client_credentials"],
	"client_name": "SYST - Danske Bank TPP",
	"token_endpoint_auth_method": "client_secret_post",
	"logo_uri": "https://danskebank.com/-/media/danske-bank/dotcom/logos/danske-bank-logo.svg",
	"jwks_uri": "https://keystore.openbankingtest.org.uk/0015800000jf7AeAAI/6cxMIpqLDWg0Dn3OPd6lH2.jwks"
}

The client_id and client_secret values should be stored for later use in the Authorization flows. Note that in 09.2019 authentication using client_secret was replaced with mutual TLS authentication and thus client_secret will become obsolete in the future. The attributes client_id_issuead_at, client_secret_expires_at contain the issue and expire date of the client_id, client_secret values.

The rest of the attributes contain information sent originally in the request.

Onboarding with eIDAS

Step 1. Obtain QWAC+QSeal certs

EIDAS is a short name for the EU Electronic Identification, Authentication & Trust Services Regulation (link). The document defines a legal framework for digital trust market in EU. Important definitions used in respect to eIDAS and Open Banking / PSD2:

QTSP – A Qualified Trust Service Provider – an organisation / company that can confirm the identity of a TPP and issue QWAC and QSealC for them. The qualified keyword means that the provided service is in line with EU laws and regulations. A list of trusted of QTSP for each EU country can be found here: link. QWAC – Qualified Website Application Certificate – certificate used for establishing secure connections in the Internet (TLS) and identifying the connecting parties. QSealC – Qualified Electronic Sealing Certificate – certificate used for digitally signing content sent over the Internet in a way that is legally bounding (non-repudation).

PSD2 and Open Banking apis (and Sandbox) accept QWACs and QSealCs for identifying TPPs (as network and signing certificates respectively). The method for obtaining them might differ for QTSPs in each country but it will most likely include the following steps:

  • TPP generates QWAC and QSealC certificate keys,

  • TPP generates CSRs for QWAC and QSealC keys in accordance to provided templates,

  • TPP submits CSRs and additional information to QTSP,

  • QTSP verifies TPPs request,

  • If the QTSP verification is successful TPP will receive QWAC and QSealC certificates signed by the QTSP.

An important element to note in QWACs and QSealCs is the ‘Authorization number’ included in organisation identifier. It’s a unique identifier of the TPP that will be the same even if different QTSPs will be used. Details are in the 5.2.1 section here: link

More information on eIDAS certificates can be found here: link1 link2 link3

Step 2. Register QWAC+QSeal in Danske Bank

TPPs that have eIDAS certificates are registered using the OAuth2 Dynamic Client Registration flow (rfc7591).

The Production TPP registration endpoint is: https://psd2-api.danskebank.com/psd2/v1.0/thirdparty/register

The Sandbox TPP registration endpoint is: https://sandbox-obp-api.danskebank.com/sandbox-open-banking/v1.0/thirdparty/psd2/register

Payload for this service is a json containing a self-signed software statement. Payload syntax is described PSD2 Onboarding Request. A sample payload might look like this:

{
	"token_endpoint_auth_method": "client_secret_post",
	"grant_types": ["authorization_code",
	"client_credentials"],
	"software_statement": "eyJhbGciOiJSUzI1NiIsImtpZCI6Ikh3TGNWZk5VYlF0cWlBaTdieHZveDhKZGJJQUdrQnUwVWxyZHNMeGV1bVkiLCJ0eXAiOiJKV1QifQ.eyJpc3MiOiJQU0RHQi1GQ0EtMTIzNDU2IiwiaWF0IjoxNTUxMTAwMzgyLCJleHAiOjE1NTExNzM5MDAsImF1ZCI6Imh0dHBzOi8vb2JwLWFwaS5kYW5za2ViYW5rLmNvbSIsImp0aSI6IjM5ZGJjYTdlMGI1MTQ5YzQiLCJzb2Z0d2FyZV9pZCI6Ijk4MjM3ZjllLWI2NjEtNDZmZS04MTYzLTE4Yzc1ZmFmM2I2ZCIsInNvZnR3YXJlX2NsaWVudF9uYW1lIjoiVEVTVC1BcHAiLCJzb2Z0d2FyZV92ZXJzaW9uIjoxLCJzb2Z0d2FyZV9jbGllbnRfdXJpIjoiaHR0cHM6Ly90ZXN0YXBwLWR1bW15dHBwLmNvbSIsInNvZnR3YXJlX3JlZGlyZWN0X3VyaXMiOlsiaHR0cHM6Ly90ZXN0YXBwLWR1bW15dHBwLmNvbS9yZWRpcmVjdCJdLCJzY29wZSI6W3sicm9sZSI6IkFJUyIsIm1lbWJlcl9zdGF0ZSI6WyJCRSIsIkhVIiwiU0UiXX0seyJyb2xlIjoiUElTIiwibWVtYmVyX3N0YXRlIjpbIkJFIiwiQ1kiLCJNVCJdfSx7InJvbGUiOiJDQlBJSSIsIm1lbWJlcl9zdGF0ZSI6WyJCRSIsIkNZIl19XSwic29mdHdhcmVfbG9nb191cmkiOiJodHRwczovL3Rlc3RhcHAtZHVtbXl0cHAuY29tL2xvZ28uaHRtbCIsInNvZnR3YXJlX2NvbnRhY3RzIjpbeyJuYW1lIjoiVGVzdCBCdXNpbmVzcyIsImVtYWlsIjoidGVzdEB0cHAuY29tIiwicGhvbmUiOiIrNDQxMjM0NTY3OCIsInR5cGUiOiJCdXNpbmVzcyJ9LHsibmFtZSI6IlRlc3QgVGVjaG5pY2FsIiwiZW1haWwiOiJ0ZXN0MkB0cHAuY29tIiwicGhvbmUiOiIrNDQxMjM0NTY3OCIsInR5cGUiOiJUZWNobmljYWwifV0sInNvZnR3YXJlX2p3a3NfZW5kcG9pbnQiOiJodHRwczovL3Rlc3RhcHAtZHVtbXl0cHAuY29tL2FwaS9qd2tzIiwic29mdHdhcmVfandrc19yZXZva2VkX2VuZHBvaW50IjoiaHR0cHM6Ly90ZXN0YXBwLWR1bW15dHBwLmNvbS9hcGkvcmV2b2tlZGp3a3MiLCJzb2Z0d2FyZV9wb2xpY3lfdXJpIjoiaHR0cHM6Ly90ZXN0YXBwLWR1bW15dHBwLmNvbS9wb2xpY3kiLCJzb2Z0d2FyZV90b3NfdXJpIjoiaHR0cHM6Ly90ZXN0YXBwLWR1bW15dHBwLmNvbS9vcGVuYmFua2luZyIsInNvZnR3YXJlX3R5cGUiOiJ3ZWIifQ.NrsfzxA9EklEeJKEN46fQj9UXP9CMw7JEYrvHUs0rI87omuhjAC1w0Cgha512ioDN5eBW3bMLr79Tolgipts5CGhDgQLm20u4H5C939tCBrR8qodWZk5Lr-PDU-OjFlPEuuhTzBkwEgf0uCaIRIHiKHijx0SrNbFqdOAGcuYC_kKSXp5g8XM1h1AXrc0hhxQ7qiMsbZW6Oj1sc1_4VTQLgkvT0muB-rk7hIWtRp1_-AJHsCqeE5cGJAWT1L7MjGDThTjczBkoK07uQVbKSnA9hEDmrH6U-_aq0mzyxtSDI4O2Vowp3p2YyYTo4xe1Oeg7zAkJYfmkwV-Gj5Hd5Ykag",
	"id_token_signed_response_alg": "RS256",
	"request_object_signing_alg": "RS256"
}

The software statement attribute contains a software statement JWT signed by TPPs signing certificate. Software statement syntax is described TPP Onboarding for EU-v24-20191025. A sample decoded software statement might look like this:

{
  "alg": "RS256",
  "kid": "HwLcVfNUbQtqiAi7bxvox8JdbIAGkBu0UlrdsLxeumY",
  "typ": "JWT"
}.{
  "iss": "PSDGB-FCA-123456",
  "iat": 1551100382,
  "exp": 1551173900,
  "aud": "https://obp-api.danskebank.com",
  "jti": "39dbca7e0b5149c4",
  "software_id": "98237f9e-b661-46fe-8163-18c75faf3b6d",
  "software_client_name": "TEST-App",
  "software_version": 1,
  "software_client_uri": "https://testapp-dummytpp.com",
  "software_redirect_uris": [
    "https://testapp-dummytpp.com/redirect"
  ],
  "scope": [
    {
      "role": "AIS",
      "member_state": [
        "BE",
        "HU",
        "SE"
      ]
    },
    {
      "role": "PIS",
      "member_state": [
        "BE",
        "CY",
        "MT"
      ]
    },
    {
      "role": "CBPII",
      "member_state": [
        "BE",
        "CY"
      ]
    }
  ],
  "software_logo_uri": "https://testapp-dummytpp.com/logo.html",
  "software_contacts": [
    {
      "name": "Test Business",
      "email": "test@tpp.com",
      "phone": "+4412345678",
      "type": "Business"
    },
    {
      "name": "Test Technical",
      "email": "test2@tpp.com",
      "phone": "+4412345678",
      "type": "Technical"
    }
  ],
  "software_jwks_endpoint": "https://testapp-dummytpp.com/api/jwks",
  "software_jwks_revoked_endpoint": "https://testapp-dummytpp.com/api/revokedjwks",
  "software_policy_uri": "https://testapp-dummytpp.com/policy",
  "software_tos_uri": "https://testapp-dummytpp.com/openbanking",
  "software_type": "web"
}.{...}

Note that the public keys in the form of jwks are hosted by the TPP. The jwks location needs to contain the certificate that can be used for verifying the software statement’s signature. A sample response from thirdparty/psd2/register endpoint might look like this:

HTTP/1.1 201 Created
Content-Type: application/json

{
	"client_id": "6cxMIpqLDWg0Dn3OPd6lH2",
	"client_secret": "...",
	"client_id_issued_at": 2893256800,
	"client_secret_expires_at": 2893276800,
	"redirect_uris": [
		"https://testapp-dummytpp.com/redirect"
	],
	"grant_types": ["authorization_code","client_credentials"],
	"client_name": "TEST-App",
	"token_endpoint_auth_method": "client_secret_post",
	"logo_uri": "https://testapp-dummytpp.com/logo.html",
	"jwks_uri": "https://testapp-dummytpp.com/api/jwks"
}

The client_id and client_secret values should be stored for later use in the Authorization flows. Note that in 09.2019 authentication using client_secret was replaced with mutual TLS authentication and thus client_secret will become obsolete in the future. The attributes client_id_issued_at, client_secret_expires_at contain the issue and expire date of the client_id, client_secret values. The rest of the attributes contain information sent originally in the request.

API Overview

The Aggregated Polling API allows a bank to deliver multiple signed event notifications to TPPs though the use of polling. It is intended as an alternative or complement to Real Time Notification in that:

  • It can be used as the sole method to collect event notifications by a TPP.

  • It offers a means to catch-up following a period where the TPP's Real Time Notification endpoint has been offline.

API Authorization

The sequence diagram below shows the HTTP requests made by TPP during authorization flow for Event notification API The authorization flow uses tls_client_auth for authentication (link) and includes:

  • [1] OAuth2 Client Credentials grant (link) for issuing temporary access token.

  • [2] TPP makes a request with temporary access token for receiving events

Event polling service

Detailed step description:

[1] TPP retrieves a temp token

TPP requests the Danske Bank’s Authorization Service for a temporary access token.

The token is retrieved using the OAuth2 Client Credentials flow (link).

A sample request may look like this:

POST /oauth2/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&client_id=...&scope=accounts

(Note that for PSD2 apis you also need to provide a country code e.g. /dk/oauth2/token) Description of the parameters used in the payload is below:

grant_type Type of authorization flow being processed. In this case the value MUST be “client_credentials” (link).

scope The scope of the token to be generated (link). For Account/Transaction api the parameter MUST contain the “accounts” keyword.

client_id The TPP identifier (link). ClientId is returned during the TPP registration as described in the onboarding tutorial.

Connecting to the token endpoint requires a mutual TLS connection with the network certificate used during TPP registration. A sample response may look like this:

HTTP/1.1 200 OK
Content-Type: application/json
{
	"token_type": "bearer",
	"access_token": "AAJANGE1....",
	"expires_in": 3600,
	"consented_on": 1548749964,
	"scope": "accounts"
}

The response is a json with the following attributes:

token_type – Type of token issued, this will be always “bearer”. access_token – Access token that can be used to create the account access consent. Access token should be included in the Authorization header in the POST request:

Authorization: Bearer <access token>

Token is valid for 1h. expires_in – For how long in ms this token will be valid. consented_on – At what point in time this token was issued scope – Repeated scope value from the initial request.

[2] TPP creates an event request

TPP creates an event describing what kind of information it wants to retrieve. Request payload is a json.

More information can be found https://openbankinguk.github.io/read-write-api-site3/v4.0/profiles/aggregated-polling-api-profile.html

Architectural constraints

State
Active

Technical constraints

Static URL
/regulatory-apis/events---psd2
Environment(s)
SANDBOX