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