In today’s instant agile-lean world, it is common knowledge that agile simply outshines old school waterfall when it comes to comparing delivery methodologies. Yet, we still see cases where both approaches peacefully co-exist and often complement each other.
One recent case in point where we witnessed and orchestrated such a harmonious yet powerful union, was during our PSD2 implementation programme for one of the world’s largest Euro clearing banks.
PSD2 as foundational stones
Most PSD2 literature, both printed and virtual, focuses on the impact on the Payment Service User (PSU) by elaborating on innovation (driving enhanced experiences and benefits) or by downplaying banks’ effort (i.e. market research indicates that 76% of banks limit themselves to mere regulatory compliance). With this article, we will illustrate how PSD2 has laid down the foundational stones for fundamental changes to the banking industry.
After requirements are well defined, the waterfall methodology begins with solution design . 44% of banks have opted for some form of outsourcing by engaging with the so called “API Hubs” (BEC, Luxhub or SIBS) which offer standardisation (mainly to secure smooth exemption requests) and needless to say reduced investment and effort in infrastructure / knowledge.
The obvious downside to this approach is a considerable limitation on a bank’s ability to innovate, and therefore differentiate, its value proposition towards third party providers (TPPs) and ultimately their customers (PSUs).
On the other end is of course the option to build an API hub in-house. Whilst it is the more expensive option to pursue, it is when done right, a solid foundation for open banking and a trigger for innovation and a brand new revenue stream. This is what we observed first hand during the implementation we drove. It is not for the faint hearted as it effectively requires the set-up of a completely new channel, front and back, that is of similar complexity to an existing web channel or app.
Solution development and implementation
Once a firm design in place, agile planning can start. The size of PSD2 requires dedicated E2E roles (delivery / test / release) to ensure build-up of each enabling capability (i.e. infrastructure, business – and technical layers) which come together into a working minimum viable product (MVP). In this phase, proper governance is key to keeping implementation on track. The main focus areas we observed were classed in the following domains
- Regulation and interpretation: While regulatory technical standards (RTS) were published 1.5 years in advance, numerous interpretations and clarification from both the European Banking Authority (EBA) and the National Competent Authority (NCA) have been published whereby agile organisation was an excellent mechanism to cope with the changes.
- Performance: Needs to be part of the design and verifications must to be made in each iteration. While performance should be as per regulation simple (i.e. mimic the existing channels), the dedicated API interface is inherently a different approach that verifies business and security rules with every API call which is different from the existing channel which runs in an authenticated session.
- Fraud: This is where PSD2 is THE game changer as risk exposure shifts. Under PSD2, the bank needs to refund the client in case of an unauthorised fraudulent transaction. Although a bank can recuperate this from the TPP, the liability and security requirements that TPPs have to comply with are on a completely different scale, which can expose a bank quickly to a range within millions. This therefore results in additional layers of defence put in place by a bank as well as a more complex fraud detection system as the TPP creates virtual devices for each PSU under the same IP address, making fraud extremely difficult to detect.
- Target Operating Model: The world of APIs is inherently a different world from web/app sessions which share a cookie to link everything together. It requires different tooling and processes to be able to continue to support the client in the same way.
We are now beyond Sep 14th 2019, is the delivery done?
- No, because PSD2 in its current form is not end-user friendly at all. Redirect mechanisms for strong customer authentication (SCA), the most common approach employed by banks does not allow for smooth app to app integration from the TPPs’ perspective. But, it is understandable that a bank would not want to make this too easy for TPPs. However, their attitude will change as soon as there is a clearly identified commercial arrangement that paves the way for new sources of incomes.
- No, because PSD2 is a new channel that needs to follow the existing channels evolutions, hence it needs to be part of portfolio management.
- No, because the first APIs are often MVPs and still need to be extended with new SCA methods and payment means.
Want to know more about how we help our clients with their PSD2 implementation? We’re always up for a good chat!