Community
One of the key features of the Revised Payment Services Directive (PSD2) and UK Open Banking is the requirement that all (almost) parties engaged in delivering the account information services (AIS) to the end user customer are authorised. This authorisation includes the conduct of the managers, the scope and maturity of the offering(s), governance and risk management controls, financial stability and insurance coverage for when a customer suffers a loss or is otherwise harmed. The stability of the ecosystem depends on this authorisation, from adoption by consumers to the overall liability model. However, there are gaps in the mechanism that must be addressed by one of two familiar means: agency or vendor management.
The intent of PSD2 and Open Banking is that the entity that has the direct trusted relationship with the end user is the party that must be authorised for the AIS or Payment Services of Initiation (PIS).
This party is referred to as the Third Party Provider (TPP). While this makes sense from a principles standpoint, it does not always work due to the commercial and technical nature of the ecosystem. Many organisations that have a trusted relationship with the consumer do not actually make the connections to the banks to collect their customers’ data. Rather, they rely on aggregation technology providers to handle that aspect of the service. So the requirements and obligations are shared by two parties, but only one may be authorised for the AIS under current regulations. There are two options available to the Account Information Service Provider (AISP) to close this gap:
1) Choosing a Technical Service Provider: In the first option, the TPP designates the aggregation provider as their Technical Services Provider (TSP) in the regulatory application for the AIS. The TPP is then required to follow the appropriate vendor risk management practices required by the regulator to obtain and demonstrate that the TSP is performing to expectations. Vendor risk management is a complex and burdensome undertaking, especially when there are downstream providers involved. If the TPP is a mature organisation, they will likely already have these capabilities so this exercise is straightforward for them. However, if the TPP is in an early stage of development, they may not have the capital available to invest in such a programme until well after launch, leaving them vulnerable. Indeed, this is exactly why TPPs choose to work with an aggregation service provider, as they specialise in providing data utility services at scale and a reasonable cost, allowing the TPP to focus on their unique value added services to their customers.
2) Becoming an agent of an authorised party: The second option is for the aggregation provider to become the authorised party (TPP) designating their client as their agent. In the agency model, the roles are reversed so that the aggregator must extend their internal control framework to their client and be accountable for them. In addition, the aggregator must be just as trusted as their clients by end users in order to function successfully. This may be more difficult for aggregators who are generally not consumer facing and don’t have the same trusted relationship that direct-to-consumer brands do. Accordingly, the end user may not sign up of the services they need due to confusion over the capabilities and relationship of the parties.
In an ideal world, I would advocate for a third option: one that addresses the downsides mentioned above, authorising both parties for the AIS and therefore making them directly accountable to the regulator and the end users. By pursuing this option, a trusted relationship can be established with the TPP and each party can carry their own obligations for conduct, quality and safety. This is the correct implementation of the principles of PSD2 and Open Banking: each party being accountable to the consumer, to each other, and to the ecosystem.
If we continue on this path, TPPs and TSPs will more than likely continue to struggle with growth, integration, and ultimately, consumer trust. While authorising AIS for all is the most logical option, we’ve got a long road ahead. Not only will challenges impact businesses relying on aggregators, and the aggregators themselves, but ultimately the very consumers using these products.The impact won’t be small either – a recent survey found that last year alone, 9% of UK adults used an Open Banking app – that’s nearly 6 million people!
I believe that two things are required from here to ensure the stable fintech ecosystem that Open Banking promised. Firstly, consumers need to be made aware of the differences in TSPs, TPPs, and AISPs. From there, Fintechs must work together and advocate for a uniform system that works for everyone.
This content is provided by an external author without editing by Finextra. It expresses the views and opinions of the author.
Ben Parker CEO at eflow uk ltd
23 December
Pratheepan Raju Advisory Enterprise Architect at TCS
Kuldeep Shrimali Consulting Partner at Tata Consultancy Services
Jitender Balhara Manager at TCS
22 December
Welcome to Finextra. We use cookies to help us to deliver our services. You may change your preferences at our Cookie Centre.
Please read our Privacy Policy.