The access of the TPP to the contingency mechanism referred to in Article 33(4) of the RTS on SCA & CSC, provided the requirements set out in points (a) to (e) of Article 33 (5) of the RTS on SCA & CSC are adhered to, has long been assumed by ASPSPs to technically constitute screen scraping with identification of the online internet banking interface, i.e. the browser-based interface.

There is however also a possibility to access payment accounts held with a specific ASPSP through the same channel as the one used by the ASPSP’s proprietary mobile banking application and that ASPSP’s back-end IT system. This proprietary mobile banking application of the ASPSP is indeed also an interface made available to the payment service users for the authentication and communication with their ASPSP.

The question is now raised as to the form that the contingency mechanism should take, and more specifically whether the contingency mechanism should only take the form of a technique allowing access to the online internet banking interface of an ASPSP (such as the screen scraping with identification technique) or whether it could also take the form of a technique allowing the access of an ASPSP’ proprietary mobile banking interface and the ways in which it communicates with the ASPSP’s IT back-end?

This question raises important issues about EU law beyond PSD2. After all the use of a technique allowing access to the ASPSP’ proprietary mobile banking interface could constitute a breach of 1) rules against computer hacking laws (such as, for instance, the Directive 2009/24/EC on the legal protection of computer programs, which may apply in case of decompilation of software), 2) rules against cyber-crimes (such as, for instance, Directive 2013/40/EU on attacks against information systems), or 3) intellectual property rights. To conclude that such a technique were to be allowed, without adding the caveat that it should not constitute a breach of any of the above EU laws, would be too blunt a statement.

In our view, this technique of accessing an ASPSP’ proprietary mobile banking interface allows for the circumvention of the application of strong customer authentication by the ASPSP. The TPP essentially requests the PSU to enroll a second instance of the ASPSP’ mobile application not on a phone under the PSU’s control (possession) but on a server owned by the TPP. It is then the TPP that selects the password or PIN code to gain access to the mobile application and not the PSU. Coupled with an amount of code decompilation and reconstitution this allows the TPP to emulate the interaction between the ASPSP’ mobile application and the ASPSP’ IT back end.

Hence the strong customer authentication that was in place through the mobile channel (possession of phone and mobile application + knowledge of PIN/password) is now entirely replaced by what is in the possession of the TPP (mobile application + PIN/password). This allows for the TPP to have continued access to all payment (and non-payment) accounts held by the PSU and to initiate payments without the PSU being involved. Hence this technique allows for the circumvention of the requirement imposed on ASPSPs to apply strong customer authentication under Article 97 of the PSD2.