Testing Facility

ASPSPs are required to provide a Testing Facility to allow authorised and pre-authorised¹ TPPs to undertake connection and functional testing of their products and services using non-PSU (i.e. “dummy”) data. The issues and problems which are identified within this testing process, as well as feedback and engagement from the TPP community, are useful for ASPSPs in alerting them to potential issues within testing that may also be encountered within the production environment. This can be used to identify and address issues early on. ASPSPs will be required to provide details and information on the outputs of their testing to their NCA as part of their application for an exemption.

This facility should² provide an accurate reflection of the live environment, and give TPP developers access to the following, with reference to EBA Guideline 6.5:

• Functionality: The facility should include all functionality of the production interface relating to AISP, PISP and CBPII use cases. This functionality should work in an equivalent or representative way to the production interface including negative use cases and error codes.
• Security: The facility should use the same security profile/model and be configured in the same way as that which protects the production APIs.
• On-boarding: The facility should replicate the on-boarding process of the ASPSP’s production facility, including TPP on boarding and the exchange of certificates for identification and message signing.
• Certificates: The facility should allow the use of both test certificates (which have the same format/structure as eIDAS certificates) and production eIDAS certificates, so that TPPs can replicate the functionality of QSEALs and/or QWACs relating to the exchange of certificates for identification and message signing, before and after they have obtained a production eIDAS certificate.
• Test Data: The facility must not include any real PSU data (RTS Art. 30(5)). The volume and variance of data should be sufficient to support all technical and functional testing including pagination (where this is supported in the dedicated interface).
• Test Accounts: The facility should provide TPPs with a number of test accounts that enable the functionality and access to data that real PSUs will experience in production.

 ¹TPPs that have applied for authorisation with their NCA and are waiting for approval

²For the avoidance of doubt, the following are all recommendations only and optional for ASPSPs, unless we are referring to direct regulatory guidance

³Participants should note the EBA feedback 103 in their final Guidelines – “Where an ASPSP is developing its authentication processes to meet SCA requirements by 14 September 2019, the EBA acknowledges that this SCA functionality may not be fully ready for testing by March 2019. However, the testing facilities should enable AISPs and PISPs to test the planned SCA scenarios, so they can accommodate these in their software and applications” [our emphasis]

• Authentication: The facility should enable TPPs to use ‘headless authentication’, i.e. authentication which does not require a PSU to be present, therefore enabling multiple tests to be run in succession via automated scripts. However, the Final EBA Guidelines have identified a new item “Guideline 6.5.(g) – the ability of PISPs and AISPs to rely on all the authentication procedures provided by the ASPSP to its PSUs”. Therefore ASPSPs must allow TPPs to test all authentication procedures³ provided to its PSUs, but ideally, ASPSPs should NOT prevent ‘headless authentication’ testing to be conducted by the TPP as well. This could be catered for by ASPSPs either:

a) allowing TPPs to test both headless and PSU authentication procedures in the same facility;
b) providing a separate testing facility in order to test all authentication procedures; or
c) allowing TPPs to test PSU authentication procedures in a production environment using their own and/or test accounts.

• Availability & Performance: The facility is not expected to handle production volumes (i.e. is not expected to be used by ASPSPs or TPPs for stress testing), however, it should have sufficient availability, capacity, performance and other characteristics to facilitate effective and realistic connection and functional TPP testing.
  • Readiness: The facility must enable TPPs to start testing their technical solutions at least six months prior to the application date of the RTS (or, if the launch of the ASPSP’s dedicated interface takes place after the application date of the RTS, six months prior to the launch date).
  • Ongoing Access: The facility should remain as an ongoing facility and to support future development or changes to the dedicated interface at least 3 months prior to the implementation of such changes.
  • Support: The facility should have an appropriate level of support to enable communication of problems or issues by TPPs to ASPSPs and to provide efficient and effective solutions.
  • Documentation: ASPSPs must publish externally a summary of the specification of the testing facility on their website including access details and test coverage.

  The testing facility should thereby enable TPPs to successfully execute full API journeys to support their proposition with the expectation that they will be able to use the same code base when connecting to the ASPSP’s production interface. In particular, this facility must ensure the API interface meets the requirements of a stable and secure connection, and the ability to exchange eIDAS and/or testing certificates. The Open Banking Standard is published on the Open Banking website.