The following questions and answers have been published in categories to make it easier to find the relevant topics. Please use the search functionality in your browser to search for specific words.
If you are new to the PSD2 API you are advised to read all of the topics below to get a better understanding of the implementation. Please also see the general documentation. 

Please also read the full API specification as the FAQ does not describe the implementation from A-Z.

Payment

Production is a live environment working on real production data. Access to production APIs is strictly enforced and limited to authorized TPPs with proper license to operate as a AISP, PISP or CBPII under PSD2 in Denmark. An onboarding must have been completed as a prerequisite for consuming the PSD2 API's. The onboarding includes register of certificates and validate license to operate as an AISP, PISP or CBPII.

On top of TPP validation - e.g. validation that TPP is properly

Sandbox provides a test environment, which allows TPPs to test the full solution including onboarding, certificates, consents, security and SCA-flows, but working on mocked data. Sandbox contains static data for Accounts and Payments and is stateless in the sense, the API's does not persist data. The infrastructure resembles the production environment and it allows a TPP to test full E2E integration - including onboarding using EiDAS certificates - prior to moving to production. 

San

In order to ensure that we have the correct information and that we can trust the certificates that are used for TPP authentication and message sealing, we need to perform an enrollment of TPP. This will be a 1 step process, where the TPP sends a signed request, in the same form as expected from Berlin Group, to an enrollment API. This process will ensure:

1. That we receive all the required certificates, including root and intermediary certificates, in a sealed and authenticated request

All API communication in the context of PSD2 will be handled by using a combination of certificates. There are 2 distinct flows that 3rd party clients need to use in every transaction:

1. Identification and Authentication
   1. This is achieved by establishing a mutual TLS connection, using a QTSP issued QWAC certificate
2. Non-Repudiation and Message Integrity
   1. This is achieving by signing each request, according to the documentation, using a QTSP issued QSEAL certificate.

Not

The diagram below depicts an overview of the flow, taking place during the creation and authorisation of a payment, including who plays what role. The respective banks responsibility is limited to the actions happening between the TPP and ASPSP. All parts of the flow are described except the SCA, which has been depicted below.
 

MitID - SCA authentication flows

In relation to payments, the SCA process is confined to the MitID process and is implemented 2-factor authentication.

The diagram below depicts an overview of the flow, taking place during the creation of consent, including who plays what role. BEC's responsibility is limited to the actions happening between the TPP and ASPSP. All parts of the flow except the SCA, which has been depicted below.
 

The SCA processes are confined to the general national authentication solutions; MitID and NemID.
NemID is in the process of being phased out as a general national authentication solution.

MitID -

The scope of this portal and the associated APIs is an implementation of the services described and specified under the PSD2 RTS:

• Account Information Services (AIS) + Consents
• Payment Initiation Services (PIS)
• Fund Confirmation Services (FCS)

The implementation of the APIs as well as the security model follows the Berlin Group XS2A version 1.3 framework. Differences from the Berlin Group specification as well as our choice of alternatives and optional features are documented in the

The APIs are made available to TPPs authorized by a local NCA (in Denmark Finanstilsynet) to operate as an AISP, PISP or PIISP under the PSD2 directive. For TPPs registered under a different national CA, they will need to passport their TPP status to operate in Denmark.

Access to production APIs is restricted to TPPs who are fully approved and authorized by their NCA to operate in the relevant roles (AISP, PISP, PIISP) in Denmark. Access to sandbox APIs is available to authorized TPPs as