How to deploy your PSD2 project: 5 recommendations
Choosing a suitable strategy and deciding on a provider to work with is one thing for banks that need to address the PSD2 topic. Implementing the chosen approach is another one. Based on our experience with payment infrastructure projects (Digicash), the joint planning efforts with our clients that are currently being carried out and the feedback they gave us, there are some key takeaways that may help to operate a smooth project management process while making sure the compulsory PSD2 deadlines are met.
Given the services we provide and the typical setup we observe in these contexts, we will focus on the scenario of a joint implementation by a bank using a hosted PSD2 platform such as Finologee’s PSD2 Compliance product. Nevertheless, most of the topics and issues listed hereafter also apply to PSD2 implementations handled by banks with their own teams or to custom on premise deployments by IT suppliers.
Irrespective of the fundamental strategy chosen, i.e. either developing an in-house solution or opt for a third-party product, implementing a PSD2 framework requires mobilising various departments within the bank, because of the directive’s substantial impact on the payment infrastructure and the scope of requirements and related features (as an example, see our recent article “Banks: have you accurately anticipated PSD2 reporting requirements?”).
Because of this wide array of topics and challenges to address it is key to have (all) the right people on board from the start. IT teams are of course at the core of each PSD2 project and IT managers, architects and security experts will do the heavy lifting, but the involvement of compliance and business teams – as well as of the payment specialists of course – from the beginning is essential to maximise the efficiency of any PSD2 compliance project.
From our experience, it often also makes sense to appoint an external advisor to help both with the gap analysis and/or the project management on the bank’s side. This can help to minimise risks and increase efficiency.
Because of the diversity of stakeholders involved, we highly recommend setting up an efficient and transparent project governance with well-defined role assignments:
- Ideally, there should be a project owner, holding the keys to the bank’s departments, with direct access to management and all relevant stakeholders. This main contact person should have the required knowledge and be empowered by the bank’s management.
- A project sponsor at the bank’s top management level will most certainly be helpful over the course of the project: PSD2 has an impact on strategy, there are going to be moments in time when strategic input will be required and choices will have to be made, also given the spill-over potential of PSD2 on CRM, customer retention/volatility and other topics. The project sponsor’s role will also be important if frictions between departments or stakeholders occur to avoid inefficiencies or lack of decision-making ability, especially given the limited timeframe for PSD2 implementation.
- All relevant departments should assign a main point of contact the project manager should refer to. This person should of course also assist to steering committees if their presence is required.
- The technology partner should make sure to shadow the different roles: a competent project manager knowing their way around PSD2, a strong technical lead empowered to make decisions and having a substantial experience in this kind of projects, and of course a project sponsor at the supplier’s management, if not a partner in the company.
It seems rather obvious that project managers on both sides should lead and coordinate the project over time. One important lesson we also learned over the last few years is that interacting directly with departments and stakeholders inside the bank as an external supplier certainly has its benefits. But the project management role should always be in control and refrain from “leaving it (only) to the specialists” to handle specific tasks or address challenges. Too often this leads to inefficiencies and questionings about roles and responsibilities, as the specialists do not always consider the big picture and have different priorities.
Finally, for complex project setups involving several entities in different jurisdictions, it becomes even more important to designate primary contact persons, clearly outline roles and responsibilities, goals and expectations, and of course make sure to agree on the overall timeline and dependencies.
First, there are quite a few PSD2 requirements one should not underestimate, because of their complexity and/or because of the workload entailed. While a third-party PSD2 Platform will handle the main part of the regulatory requirements out of the box, some substantial efforts are still required on the banks’ side to enable, given the nature of the features to be implemented:
- A connection to the bank’s backend/payment systems is required, to initiate and validate payments and retrieve account information to be provided to the TPP,
- The bank’s authentication mechanism must be linked to the provider’s authorisation platform to provide SCA functionality,
- Finally, the security aspects will also require some efforts on the bank side. Indeed, a secure and trusted connection should be used (such as TLS mutual authentication, IPSec VPN, OpenID Connect)
Secondly, some PSD2-related issues are not fully ‘stable’ yet, in terms of definitions, analysis or because of the lack of position statements by relevant authorities such as the EBA or the regulators. Here are a few examples:
- Conditions for a fall-back mechanism under PSD2 and conditions to benefit from an exemption from the contingency mechanism (a last opinion has been published by the EBA on December 4, 2018)
- PSD2 technical specifications (such Berlin Group or STET) keep evolving – stabilized version would probably be expected only for the second quarter of 2019
In addition to this, because of the existence of certain grey areas in the PSD2 sphere that have not been fully addressed by the EBA, the ECB or national regulators quite yet, an essential recommendation for project managers and solution architects in charge of PSD2 implementations is to place the RTS and their updates on the top of their reading lists for the coming months, and to keep an eye on any relevant EBA papers and PSD2 position statements from regulators.
In order to accurately anticipate the three main PSD2 milestones set out for 2019, we strongly advise to define a suitable roadmap, starting from the known deadlines and working your way back to the present time. Again, this might sound quite trivial, but this allows you to gather the required elements, approvals and input proactively, as well as to be prepared for the next step. For example, as of today, business requirements definitions and sandbox implementation should already have been kicked off, including SDKs, sample data for the different APIs, documentation and integration of this sample data. As a next step, the most intensive phase of the project will be held between March and June 2019.
For inspiration, here is an example of a top-level timeline we have agreed on with some of our clients:
As stated above, PSD2 deployment within a Bank requires the involvement of various functions: project, IT, compliance and business. Given the fact that there are absolute deadlines to be met – if you do not want to be subject to penalties – coordination, anticipation and a thorough project and priorities management are highly recommended.
PSD2 Compliance is about opening up your payments infrastructure to third parties. This comes with multiple layers of complexity and a variety of challenges. Even when choosing and external platform solution, the overall workload should not be underestimated, especially given the fact that some tasks can only be carried out sequentially and require some strategic decisions.
One more for the road, at a more strategic level: start your thinking process early enough to specify what your position in the market and your strategy in a post-PSD2 world will be.
- Do you want to play offense, or is it more a defense game you want to go for?
- Do you want to empower your clients to actively use PSD2-based features with TPPs?
- Do you envision to expose additional data sets, features or products via API, beyond PSD2?
- What will be your strategy partnering or competing with your peer banks, how much do you want to – and how much can you afford to – rely on them or depend on their strategic choices?
Please feel free to suggest other recommendations with regards to PSD2 implementation projects, and we’ll happily integrate them into this little guide. Also feel free to ask any question you might have.
About Finologee
As a FinTech player, Finologee is providing a PSD2 Compliance product and platform enabling any financial institution holding payment accounts to meet PSD2 technical requirements quickly and easily. PSD2 Compliance for Banks, its processes and flows have been designed and developed accordingly to match the PSD2, RTS and related provisions and obligations. Finologee’s product encompasses the security layer and access to account rules relying and fully compliant with the EBA guidelines and the PSD2 directive (based on audit trails, statistics on TPP access). The current ((December 2018) implementation scope of the product is 21 banking entities in 7 EU countries.
