Sorry, you need to enable JavaScript to visit this website.


The PSD2 APIs are available in two environments:

  • Sandbox: A mocked environment allowing TPPs easy access to APIs to test  integration with business functionality of APIs. Sandbox follows same security model, enrollment and SCA-flows as seen in the production APIs. Hence, once tested in sandbox, it usually only requires a change of endpoints and certificates to migrate to production.
  • Production: Real production APIs working on live production data. Access to production APIs is strictly limited to authorized TPPs with proper license to operate as a AISP, PISP or CBPII under PSD2 in Denmark. A (one time automated) onboarding step is required for TPP to register certificates and validate license to operate as an AISP, PISP or CBPII

On top of the Sandbox And Production environments, BEC's PSD2 solution provides separate environments for all banks under the BEC umbrella. Hence, when integrating to the APIs, the TPP must both consider the environment (sandbox vs production) as well as which specific bank to integrate with.

As of August 30, all portals, sandbox- and production endpoints are provided per bank. See list in above link for a fulllist of banks and endpoints.

Since all banks reside under separate URLs, E.g. to use PSD2 solution from Vestjysk Bank use endpoints under while e.g. would use PSD2 solution from Spar Nord Bank A/S.

The sandbox and production environments are elaborated below.


Note: As of September 2019, the isolated, purely mocked sandbox environment has been replaced by a new environment with support for security solution, consents and SCA flows. The new sandbox still works on mocked data, but the infrastructure now much more resembles the production environment and it allows a TPP to test full E2E integration - including onboarding using EiDAS certificates - prior to moving to production. The old sandbox will be decommisioned. TPPs that have previoously signed up to the portal and created a sandbox subscription, will no longe be able to access the sandbox using client_id and client_secret and old sandbox API endpoint will no longer work. Instead the TPP will need to follow the normal onboarding flow to enroll and register at the sandbox.


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.

Sandbox implements the same security model based on eIDAS certificates as production. The security context cannot be configured or set up from the developer portal, and access to sandbox APIs does not require signup or subscription from the portal. Refer to the description of production environments for description of URL schemas. For sandbox access, replace psd2api with psd2testapi in the examples.


Hence a full sandbox URL path to access accounts API at Nykredit Bank (bank 32) would be:

Note on certificates:

For licensed TPPs, the real production eIDAS certificates (QWAC + QSEALC) can be used. The production and sandbox environments are kept 100% separated, even when production certificates are used in sandbox. And additionally, within each environment the diferrent banks under the BEC umbrella are also kept 100% separated. Hence, enrollment, consents, account data etc from one environment or bank will neve be able to affect any of the other environments.

If its not feasible for TPP to use production certificates in sandbox, or if TPP is not yet fully licensed, but has the application pending at a national FSA, please contact us on to arrange for provisioning test certificates for use in the sandbox. If you already have a set of test certificates issued by an official QTSP, also get in touch with us at above email to ensure that QTSPs CA and intermediate certificates are installed on our end.


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 licensed and entitled to call the API in the first place - the production environment also enforces SCA on behalf of PSU in connection with consent handling and creation and authorization of payments. Please refer to the linked flows for details of production SCA flows.

Production APIs can only be accessed directly from a TPP client - it is not possible to setup security context or test against the production APIs from the development portal.

Hence all TPP access is by calling the production API endpoints directly. All production APIs share a common schema for hostnames and URL path Components. The general schema for production host URLs is


Where banknumber is taken from the list of provider banks.

The schema for URL path components is:

/eidas/{api_implementation_version}/{Berlin Group Version}/{endpoint}

The meaning of each component is:

  • eidas: The security model used for securing the API. Only eidas is supported at the moment.
  • api_implementation_version: Used for versioning of API implementation. Follows semantic versioning. Used when a new implementation of the API involves a breaking change. All APIs are currently at 1.0. Version number is specified in the published Swagger specifications and API description.
  • Berlin Group Version: Part of Berlin Group specification. Specifies the version of Berlin Group API framework. Currently only v1 exists
  • endpoint: The API endpoint (accounts, payments etc)

Hence a full production URL path to access accounts API at Nykredit Bank (bank 32) would be: