Non-dedicated interface - is it really worth cutting costs now?

This is the second piece from a series of articles about non-dedicated PSD2 interfaces. While the first article lists the requirements imposed upon PSD2 interfaces and how banks can implement these, the second article covers the challenges of launching and maintaining a non-dedicated interface.

In regards to technical requirements, there is no much difference for dedicated and non-dedicated PSD2 interfaces. Article 30 of RTS, that stipulates the requirements that PSD2 interfaces should meet, refers to both dedicated and non-dedicated interfaces. Providing a non-dedicated interface (i.e. adjusting the existing PSU facing interface) seems to be a quite fast and inexpensive (at least in the short term) compliance solution. Yet, taking into account all PSD2 requirements, the cost of maintaining the testing facility and the cost of updating the actual live environment will increase significantly over time. This factor might eventually prevent the ASPSPs from making updates and improvements to their non-dedicated PSD2 interfaces.

Besides the cumulative high cost of maintenance, it is challenging to implement several critical PSD2 functionalities and to conduct certain actions via the non-dedicated interface:

• Setting up a mechanism for confirmation of funds for PIISPs (CBPIIs);

• Implementing the usage of eIDAS QWAC certificates for Mutual TLS and eIDAS QSEAL certificates for signing the TPP requests via non-dedicated interface is more difficult;

• Implementing the SCA exemption for 90-days access for AISP (Article 10 of RTS on SCA) is quite challenging in the non-dedicated channel. It requires adjustments to the existent PSU facing interface and these changes, if not made correctly, can jeopardize the security of PSU data.  Thus, it is relatively more complex (compared to implementation in dedicated interface) and requires a sequential process i.e. initial security risk assessment and then the actual implementation;

• Onboarding TPPs automatically on the non-dedicated interface is challenging;

• Receiving additional attributes from TPP about PSU session (i.e. IP address, location, user agent, OS, etc.). This information could be used by banks for various reasons like anti-fraud, for deciding to apply the SCA exemption or not, etc.;

• Supporting different types of PSD2 exemptions for payment initiation (e.g. contactless payments at point of sale, recurring transactions);

• Calculating the number of AISP attempts to access the payment account and detecting whether the PSU is present. Requesting access and fetching large amounts of information many times a day can overwhelm the PSU facing interface (i.e. online banking). That is why a limit of 4 times was set (under PSD2) for TPP access for fetching account information.

When choosing to provide a non-dedicated PSD2 interface, ASPSPs should consider factors like the cumulative cost of implementation and maintenance of the interface, the possibility to meet all the imposed legal and technical requirements, the correct implementation of security measures, TPP identification procedures, documentation, interface updates notification system, and others. If it’s challenging to deliver at least one of these, then banks shall revise their decision. Otherwise, the short term cost-cutting will result in long term headache.

The alternative is providing a dedicated PSD2 interface. Besides being more flexible, it gives visibility over the TPPs’ actions via the interface. ASPSP wishing to develop and launch a dedicated PSD2 interface in a faster and more affordable way than building it in-house can rely on technical service providers that can help with the implementation.

Let’s remember that the main beneficiary of PSD2 is the PSU and the directive requires both ASPSPs and TPPs to provide reliable and secure services that are in the best interest of the PSU, regardless of the interface type. Initially, ASPSPs and TPPs will struggle during the provision and consumption of PSD2 interfaces, yet, the collaboration and an efficient feedback loop from both sides will lead to fast adoption of endless Open Banking possibilities.