Dedicated Interface Requirements
Other pages in this section
ASPSPs are required to provide a Testing Facility to allow authorised and pre-authorised1 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 should2 provide an accurate reflection of the live environment, and give TPP developers access to the following, with reference to EBA Guideline 6.5:
1TPPs that have applied for authorisation with their NCA and are waiting for approval
2For the avoidance of doubt, the following are all recommendations only and optional for ASPSPs, unless we are referring to direct regulatory guidance
3Participants 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]
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; orc) allowing TPPs to test PSU authentication procedures in a production environment using their own and/or test accounts.
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 OBIE Standard is published on the Open Banking website
ASPSPs that use the OBIE Standard, or any other market initiative, should publish the details of the specifications on their website six months prior to the publication date in 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). Should an ASPSP deviate from the Market Initiative they have adopted, they should inform their NCA with details of what changes they have made and an explanation of the rationale for the deviation.
Implementations of the specifications should be machine readable, so that TPPs can automate discovery, and include the following details by brand/product:
Should any of these details change at any time, the ASPSP should notify TPPs by updating their website (e.g. through a change log) as detailed in Chapter Change and communication management.
Design & Testing Previous
Stress Testing Next