The European Banking Authority’s (EBA) has published its long-anticipated draft Regulatory Technical Standards (RTS) on ‘strong customer authentication and secure communication’ on 12 August. The RTS are considered key to achieve the PSD2 objectives of enhancing consumer protection, promoting innovation through competition and improving the security of payment services across the European Union. Many industry actors are working hard to understand the legal, operational, functional, technical and business implications of the RTS. In this blog, we elaborate on three key RTS business implications for banks:
- Banks can leverage PSD2 ‘Access to account’ (XS2A) compliance as a catalyst for developing their API strategy, but they do not have to develop one if they do not want to
- As expected, the RTS do not provide us with technical specifications that one can actually implement. Additional work by ‘the industry’ is required
- Banks remain in control of their own security. They do not have to trust a TPP 'because the TPP says so'
Let us explain in more detail what we mean with these business implications.
1. Banks can leverage PSD2 XS2A compliance as a catalyst for developing their API strategy, but they do not have to develop one if they do not want to
In our previous blog we have discussed four strategic options for banks to react to PSD2 XS2A. Banks that are already exploring a strategy based on a more ‘open business model’, benefit from the drive towards openness triggered by PSD2. These banks are developing various services to offer to other service providers in order to provide more value for their mutual customers. PSD2 compliance is considered as yet another strategic investment that contributes to the establishment of a more open business model in banking.
You can very well imagine the mandatory Account Information Service (AIS), Payment Initiation Service (PIS) and Confirmation on the Availability of Funds (CAF) as a freemium model on top of which a premium model of more integrated services can be built. In this way the budgets for PSD2 compliance directly contribute to funding a foundation layer of services that facilitates the bank’s open business model that goes beyond the regulatory requirements of PSD2.
However, if a bank does not seek to pursue such an open business model strategy it can also just focus on being compliant. This merely requires adopting the right method of strong customer authentication, slightly adapting and documenting the bank’s web interface for internet banking to comply with RTS requirements for Third Party Provider (TPP) authentication and ISO20022 formats. Banks will also need to provide a testing facility and communicate any changes to the interface as soon as possible, not less than 3 months before the change is implemented. In this case the bank can just be compliant and allow TPPs the minimal form of access as defined in PSD2. Nothing more, nothing less.
Our advice: carefully determine the strategic position as bank (what do you want to be to your customers) and act accordingly and consistently.
2. As expected, the RTS do not provide us with technical specifications that one can actually implement. Additional work by ‘the industry’ is required
Ideally, there would be a single message and interface standard and infrastructure with full pan-European reach for XS2A transaction services. This would maximise the benefit for end-users (payees and payers) and ultimately provide for a positive ‘market ROI’ on PSD2 compliance investments. This could be seen as the implicit promise of PSD2.
However, considering the current draft version of the RTS, we are nowhere near such single standards. In the RTS the EBA encourages ‘the industry’ to develop compliant standards and/or technological solutions to complement the ‘principle-based’ RTS requirements. But what exactly is ‘the industry’? Who should take the lead in this? And when should such collaborative effort start, considering the foreseen enforcement date of the RTS (Oct. 2018 earliest)?
The RTS triggers more questions than actually providing answers in this regard. What we do know is that an individual bank can implement its own ‘standard’ to comply with all PSD2 and RTS requirements. Also clear is that the promise of realising Pan-European interoperability from the start, will only be fulfilled if a single or limited set of standards, or even ‘scheme’ (i.e. set of commonly agreed functional, technical, operational and governance rules) will emerge. As a result of the latter, we already see several initiatives (e.g. CAPS, Preta, Berlin Group, UK Open Banking Working Group) emerging across Europe. And what you would be afraid of is already happening, these initiatives are differing on three essential dimensions as also depicted in figure 1:
- Scope of ‘openness’: ranging from PSD2 compliance only to enabling banks to reap the business opportunities of open business models;
- Scope of standardisation: ranging from pure technical and functional requirements to full set of operational and governance rules to operate XS2A transactions;
- Scope of collaboration (‘reach’): ranging from individual bank driven efforts to combined bank and non-bank collaborations on national or regional level.
Our advice: as no-one knows what initiative will be successful and deliver technical solutions in time, we advise to actively monitor relevant standardisation initiatives, participate in the most promising initiatives, strive for a Pan-European solution where possible, but prepare for more local/individual action, to mitigate the risk of non-compliance by October 2018 (earliest).
3. Banks remain in control of their own security. They do not have to trust a TPP 'because the TPP says so'
At the center of PSD2 we find requirements on strong customer authentication. These requirements ensure that security of funds and information is guaranteed even when communicating through TPPs outside the bank’s domain. Although this means that many European banks need to invest in their authentication technology, the good news is that a bank can enforce the use of (new) technology throughout its customer authentication procedure, whether it is directly or via a TPP. Only under an additional contract a bank could optionally allow for customer authentication through TPP issued credentials. Such agreements are outside the scope of PSD2.
Our advice: Carefully choose partners and base partnerships on clear agreements that address communication, support and liability towards the customer.
The RTS are not just principle-based requirements aiming to provide guidance to make XS2A work in practice. Rather the RTS have far reaching business implications for banks shaping their competitive position in the PSD2 era. Do not hesitate to reach out to us if you would like to discuss these and other implications further in order to act accordingly.