top of page

With the aim to leverage the NextGenPSD2 API Framework technology and infrastructure investments, openFinance allows banks, Third Party Providers (TPPs) and other Access Clients to offer enhanced services, products and information that will benefit market participants and will further improve customer experiences. Berlin Group openFinance adds standardised extensions beyond the regulatory PSD2 scope that enable bank customers (consumer or corporate account owners), directly or via TPPs and other Access Clients, to access bank accounts for commercial premium services and enriched data.

By expanding the access of customers’ financial data to broader data sources and additional account types, enhanced views on customers’ finances are offered which will empower bank customers to actively choose the best value products and services they need. openFinance will improve the basic credit transfer with additional functionalities (e.g. flexible execution and document handling) and enables the creation of many other new payment and credit services. The openFinance services will attune to the ambitions of the European Commission’s Retail Payments Strategy and to any relevant future scheme definition.

​

Please have a look at the General Introduction Brochure with further details on Berlin Group openFinance.

Please have a look at the Workplan 2024 for the future planned openFinance services.

  • 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.
  • 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.
  • 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.
  • 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.
  • 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