top of page

PSD2 Access to Bank Accounts

Based on the requirements of the revised Payment Services Directive (EU 2015/2366, also known as PSD2) and of the European Banking Authority Regulatory Technical Standards (EBA RTS), Berlin Group NextGenPSD2 has worked on a detailed 'Access to Account  (XS2A) Open Banking Framework' with data model (at conceptual, logical and physical data levels) and associated messaging.

​

Berlin Group NextGenPSD2 has been implemented in all EU countries (mostly on a national basis), in several non-EU countries in Europe and in countries outside Europe who are focused on maintaining reachability and compatibility with the European market. More than 75% of European banks and hundreds of Third Party Providers (TPPs) have implemented the Berlin Group NextGenPSD2 Framework.

​

While the NextGenPSD2 Framework is considered as finalised and mature, any new PSD2-relevant clarifications from EBA or National Competent Authorities (NCAs) will continue to be integrated into the NextGenPSD2 Framework. Since 1 January 2021 the NextGenPSD2 Framework has become an integrated part of the Berlin Group openFinance Framework. The openFinance Framework aims to leverage the NextGenPSD2 Framework technology and infrastructure investments with standardised Open Finance extensions beyond the regulatory PSD2 scope that will enable bank customers (consumer or corporate account owners), directly or via a Third Party Provider (TPP), to access bank accounts for commercial premium services and data.

​

Please Note: On this webpage only the 'Archived information' section below may be updated infrequently, when new publications are announced on the dedicated NextGenPSD2 download page. Open Finance updates are provided on the openFinance website.

​

​

History NextGenPSD2

 

Berlin Group NextGenPSD2 developed uniform and interoperable XS2A communications and this helped tremendously to

  • provide TPPs with uniform access to the market and optimal reachability;

  • reduce the PSD2 XS2A complexity and fragmentation risks;

  • save costs and risks on development, documentation, implementation, maintenance, testing and operations;

  • generate better, more, cheaper and faster time-to-market services for bank customers;
     

The NextGenPSD2 Taskforce represented the market supply-side (i.e. banks, payment/banking associations, payment schemes and interbank processors operating in SEPA), which was mandated by PSD2 and EBA RTS to provide an XS2A interface and is also liable for any operational damages. The NextGenPSD2 Framework covers the requirements from almost 70 participants from more than 25 payment communities on amongst others consent models, SCA architectures and related payment products for retail and corporate business.

​

The NextGenPSD2 Taskforce was supported by several Working Groups, by a NextGenPSD2 Advisory Group & Board and with feedback via market consultations and other direct channels. Since 2021 the NextGenPSD2 Taskforce migrated into the openFinance Taskforce and the Advisory Group & Board migrated into the openFinance Advisory Group & Board.

​

NextGenPSD2 Deliverables

​

The NextGenPSD2 Framework itself is built of 4 artefacts, which are all published for free under Creative Commons (CC-BY-ND):​

  1. An Introductions Paper;

  2. An Operational Rules document that covers the service description, abstract (logical) data model and detailed process flow descriptions in a B2B interface;

  3. Implementation Guidelines that specify the XS2A interface in technical detail, including XML/JSON schemas. In addition to the core Implementation Guidelines, an Appendix document with domestic payment definitions has been published.

  4. An OpenAPI file that helps implementers during development;

 

The documents were and are still used by banks and TPPs for implementing PSD2-required bank account access. Technical errata, clarifications and additional functionality required by EBA or NCAs might still be published here where you can also find all above-mentioned and updated NextGenPSD2 deliverables available for download.

 

Implementation Related Information

​

While the NextGenPSD2 Framework focuses on standardisation and implementation support is out of scope, the NextGenPSD2 Taskforce would still like to make sure that TPPs are able to find NextGenPSD2 implementers and are involved and supported for testing. This section provides links to NextGenPSD2 implementation support sites where TPPs can register for testing and find testing support (from e.g. test directories with BICs of banks, URL testsandboxes, NextGenPSD2 version information, etc.):
 


Any new implementer support information can be sent to info@berlin-group.org and will, after validation, be listed here as well.

  • 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.
bottom of page