Wannabe PSD2 Compliant? Change the internal modus operandi!
Banks are already used to difficulties. They have to comply with domestic and international laws, policy makers adjusts their operating environment according to their daily interests, and they have to fulfill regularly changing reporting obligations. Among all this muddle, PSD2 stands out as a special can of worms, representing an on-going pain in the neck for financial institutions.
Why is it so? The revised version of the EU Payment Services Directive ("2nd PSD") was published in 2016 and has been regularly supplemented by technical standards (RTSs) or recommendations. Compliance with the latter is not obligatory -- in theory. Banks are only required to make “an honest effort” to comply. But the Hungarian National Bank, serving as a supervisory body, regularly translates and publishes them as its own regulations, so domestic banks have to adapt to it. (Just a footnote: PSD2 does not only apply to traditional banks but also to payment service providers, such as fintech companies. So think twice before you launch your own revolutionary fintech startup. Just some knowledge in coding and online marketing with some banking experience, will not suffice.) PSD2 specifies such a complex set of rules for the banks that they are practically unable to comply with in their traditional operating model. In spite of the supervisory fines and all the effort made for prudent operation, sooner or later they will be caught in the net -- because the underlying fault is in the system.
Let's have a look at how the compliance process works today in practice. Let's assume that a new PSD2 specification appeared on the EBA (European Banking Authority) website and with some delay it was also published in the official Hungarian Journal. As a first step, the legal department (and possibly compliance) must realize that a new piece of PSD2 legislation was published, even if it is hidden in a potpourri of legislations. Next, they have to interpret the law to determine if it applies to the bank at all. If so, they need to find the department within the bank that can decide from a professional point of view what specific actions should be taken to comply with the new regulation.
The beauty of PSD2 is that the regulations are likely to affect several departments. Let's say a new regulation is published on incident management. To ensure compliance several departments -- IT, bank security, legal, communication, and even reporting – must work together. The result of the collaboration may be a new internal policy and/or some development, but even new work roles can be created. Moreover, the innovation is not a one time work, but it has to be integrated into the daily operation.
Let's be honest: these things don't run smoothly most of the times. Typically, the work is delegated to an unfortunate department. They desperately try to get some help from the other departments, which they either get or not depending on how much is on their plate. Sooner or later the work will result in something presentable, but a prayer will be needed at every audit, so that the supervision would not spot the weak points.
Of course, we can say that this is how banks work, you have to live with it. But will the shareholders live with it when the bank receives hefty fines for non-compliance over and over again? Supervisory fines can spoil the revenues badly, not to mention negative publicity.
As I pointed out, there always difficulties, but it really matters how grave they are. Two things can greatly help to have at least some chance to comply. The first one is that the departments in the bank should start to consider each other as internal customers and internal suppliers. It must be realized and accepted that IT is the supplier of the compliance department in certain situations and at other times it is the customer of the legal department. It doesn't work that way that we, the bank are one side of the trench and the customers are on the other side! In an in-house project, the customer of the IT department is not the end user but rather the other department they are working for.
And if this notion takes hold it will fundamentally affect operations. If I am a customer of another internal department, I can formulate precise requirements for them (or I am even expected to formulate those). On the other hand, they, as a supplier, have accountable obligations to me. It is no longer that “I will help you where and how I can”. When it comes to compliance projects, it is very useful if accountable and responsible roles are separated. If work is done through pre-assigned processes then everyone knows what their work is and how they contribute to success. (I wouldn't explain the content of the RACI matrix here.)
How would a project look like in this environment? The legal department detects that a new regulation has been published. Based on pre-defined processes, they will notify the relevant areas of expertise (departments) and at the same time they will also report to the designated senior manager (who will likely be the future sponsor of the project). Within a few days, a decision will be made about which department will be accountable for the success of the project and which departments will help them as internal suppliers (responsible parties).
There's got to be a project manager as well. He or she doesn’t have to be a black-belt banking expert. His/her job is to ensure that the project is handled well from a methodological point of view. The professional banking issues will be solved by the specific departments. This way, most of the contingencies can be taken out of the system, and the first, perhaps most difficult steps on the road to compliance have already been taken.
So let's not forget two things. Inside the bank, consider each other as customers and suppliers (and behave accordingly!) And, on the other hand, develop processes do deal with compliance issues, from the detection of new regulations through actual work to control. And if we add some financial incentives to the equations – hand out substantial bonuses for successful audits, for example - we can face the next PSD2 amendment with fundamentally different expectations.