top of page

NextGenPSD2 Downloads
Last updated: 24 June 2025

License Notice
More information
Click the arrow in the table to sort entries
Click the blue-coloured links to download documents
IMPORTANT: The Berlin Group NextGenPSD2 OpenAPI (YAML) files are available on GitLab at: https://gitlab.com/the-berlin-group/nextgenpsd2
 

Archive​

Further archived files are available upon request here

License Notice

This page offers the most recent version of the NextGenPSD2 Access to Account Framework documents. The documents are offered for free. When downloading documents from this page, you agree to be bound by the following Berlin Group license conditions:

​

  • “Creative Commons Attribution-NoDerivatives 4.0 International Public License”






    This means that the Specification can be copied and redistributed in any medium or format for any purpose, even commercially, and when shared, that appropriate credit must be given, a link to the license must be provided, and indicated if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use. In addition, if you remix, transform, or build upon the Specification, you may not distribute the modified Specification.

​

  • Any OpenAPI files offered by Berlin Group are bound by “Creative Commons Attribution 4.0 International Public License” and are allowed to be changed. However, please note that the normative reference still is the Implementation Guidelines document.

​

  • Implementation of certain elements of this Specification may require licenses under third party intellectual property rights, including without limitation, patent rights. The Berlin Group or any contributor to the Specification is not, and shall not be held responsible in any manner for identifying or failing to identify any or all such third party intellectual property rights.

​

  • The Specification, including technical data, may be subject to export or import regulations in different countries. Any user of the Specification agrees to comply strictly with all such regulations and acknowledges that it has the responsibility to obtain licenses to export, re-export, or import (parts of) the Specification.

​

Creative Commons
License Notice
  • As a bank we have very specific needs in our markets. Is NextGenPSD2 leaving us sufficient room to accommodate our own specific needs or is it only offering a ‘one-size-fits all’ solution (with the risk that it fits no one)?
    For core payment products in the European market, NextGenPSD2 is defining the payment initiation process and the way how messages are steered for all banks in the same way, e.g. via pre-defined API endpoints and common JSON structures. However, banks may in addition offer more extensive JSON structures that they would like to use in order to accommodate payment products they are supporting within their country, region, community or within their own online banking system. So NextGenPSD2 is able to support different business practices and offers multiple degrees of freedom to accommodate non-standard payments and formats, still based on the same unified dictionary. More information can be found in chapters 10 and 11 of the Framework Implementation Guidelines.
  • Can we as a ‘FinTech’ startup also participate to the future development of NextGenPSD2?
    Certainly. The current governance restricts NextGenPSD2 participation to the supply-side of the market that is mandated by PSD2 and EBA RTS to provide an XS2A interface and is liable for any damages. However, after the public market consultation and publication of the first version of the standards (scheduled for the end of 2017) NextGenPSD2 aims to provide a more permanent structure that involves broader market interests as well. The exact details are likely to become available in Q1 2018.
  • Is the API specification supported by a (self-)test / (self-)certification process?
    This will be discussed as part of implementation support. This could also be complemented by NextGenPSD2 defined minimum certification requirements in order to assure a solid and reliable level of interoperability and secure message exchange.
  • We are operating as a bank. If we participate to the standardisation work are we then bound to NextGenPSD2 implementation?
    Although you are obviously very welcome to start implementing the NextGenPSD2 Framework, NextGenPSD2 has no formal means and mandate to foster implementation of the standards. NextGenPSD2 has been established as a pure technical standardisation body, focusing on detailed technical and organisational requirements to achieve interoperability and harmonisation in the inter-banking domain. As such, NextGenPSD2 is not engaged in the implementation of standards by the market. Therefore, participation to NextGenPSD2 does not imply a commitment to implement. Decisions on the implementation of the standards delivered by NextGenPSD2 are left to individual market participants and implementation support will be organised separately. Support for implementation experience and feedback will be linked into the standardisation work to support implementers with questions and migration planning, to identify and manage interoperability or technical implementation issues relating to the specification standards and to keep the standards in line with the requirements of real practical implementations. As such it is expected that implementers will provide an important driver for changes and to the further evolution of the standards and related change management process.
  • Are you supporting mutual authentication between TPP and ASPSP?
    Yes. At the transport layer TPP and ASPSP are always identified/authenticated by means of the client and server authentication which is part of the TLS-connection setup between the TPP and the ASPSP. For this identification the TPP needs (as mandated by the EBA RTS) a qualified certificate for website authentication according to eIDAS, also compliant with the additional requirements defined by the EBA RTS. NextGenPSD2 and EBA RTS do not set any requirements on the certificate type of the ASPSP. If requested by the ASPSP, the TPP can also be identified at the Application Layer level by signing all messages sent to the ASPSP. The electronic seal (i.e. the electronic signature) and the certificate of the TPP have to be sent to the ASPSP as part of the message. The TPP needs a qualified certificate for electronic seals according to eIDAS, also compliant with the additional requirements defined by the EBA RTS.
  • Does the API allow for a combination of AIS and PIS services?
    Yes. A combination of the services in the PSU/TPP interface is anyhow possible. Further on, transactions belonging to different services can be mixed already in the TPP/ASPSP API within a single 'session' if an ASPSP supports this. This means that a TPP can, for example, request information about accounts of a PSU before initiating a payment on behalf of the PSU without authenticating the PSU more than once. Note that also in this case, a separate SCA might be required by the ASPSP due to PSD2 compliance. This will also be reflected in the future SCA behavior of the Online Banking systems.. The roles of the TPP have to be included in the qualified certificate of the TPP. Whether the ASPSP supports combination of services or not will be stated in his documentation. The ASPSP might require the TPP to use an AIS registration confirmation when accessing the interface for account information during a payment initiation request.
  • Will there be a licensing policy for the NextGenPSD2 Framework?
    The Notice at the start of the existing specification documents expresses the permission "to use the document solely for the purpose of implementing the Specification...". When publishing the final version of the NextGenPSD2 Framework, it may be decided to make the implicit copyright expressed in this permission more explicit, acknowledging the Berlin Group principles that standards specifications are provided free for use, should contribute to the harmonisation objective of the Berlin Group and obey transparency in scope and participation conditions. Therefore it is not allowed to modify the specifications in whatever way outside of the Berlin Group work, to create any derivative works, or to develop, distribute and/or sell any modified version of the specifications in software applications, as this would affect these principles.

More information

More information
Archived files
bottom of page