Despite numerous concerns, PSD2 primarily represents a unique strategic opportunity for (would-be) Third Party Providers (TTPs), including the banks, if only they have the courage and the innovative power to seize and unfold it. All types of companies can become a TPP if they so desire, as long as they fulfil the national requirements for TPP approval. This means that many different types of TPPs are expected to emerge within the market.
To become a PISP or AISP
Some TPPs will come from the financial services sector and include FinTech companies like the current “direct access” players such as Klarna and Trustly. Banks can become TPPs themselves to tap into competing banks’ accounts if they want to launch payment solutions themselves (as a Payment Initiation Service Provider), or launch information/data aggregating services in the role of an Account Information Service Providers (AISP).
It’s also a logical step for existing payment service providers offering acquiring and acceptance solutions to become TPPs. And also, some TPPs will come from outside the traditional financial services players, e.g. telecom operators, transport and insurance companies, utility providers, public authorities, merchants and many more.
The broad range of TPPs has the potential to accelerate a whole new wave of financial services innovation on top of or in collaboration with the banks. These new opportunities are key reasons why creative and forward-thinking banks might be in favour of the access to account requirements. But, more than this, the requirements of PSD2 might galvanize the banks to start using open APIs more broadly (although there is no obligation in the directive for the banks to do so).
Below are five important steps for market players who consider becoming a TPP, following the PSD2:
1. Business case – where to play?
Similar to any other type of new business, a TPP must define its business case. What do you set out to do in the first place? Your strategy as a TPP will vary greatly whether you are a bank looking to aggregate account information for your customers across other banks or if you are a FinTech start-up looking to introduce a revolutionary account-based payment solution. In most cases scale will be of essence, and you as a TPP should have a clear tactical plan for scaling the reach to the banks required to gain critical mass. But also, a large reach towards merchants to cross sell and push complementary offers.
2. APIs – How to get API definitions from the banks and how to ensure performance?
To realize the business case a TPP must rely on certain key factors from the banks. First and foremost, the quality, reliability and stability of the interfaces/APIs towards the banks and the underlying infrastructure. Secondly, the scalability of these interfaces (again including the underlying infrastructure). Banks are experienced in operating stable and resilient platforms, but might not be experienced in delivering APIs to the outside world. This means that a TPP will rely on a given bank’s capability or choice of strategic supplier of the APIs.
What has been decided upon with PSD2, is that banks must be able to offer a dedicated interface managing account access for TPPs based on common and secure communication standards: it seems that open APIs will cover this need, but industry standardization is in progress.
3. Target scope – Am I targeting a specific country, sector, or just go for the biggest possible scale? Does my strategy depend on cross-border interoperability?
While one of the best things about PSD2 is that it applies to all EEA countries, it would be a daunting task for any TPP to connect to all of Europe’s 4,000 banks. An aspiring TPP would need to define its target scope and expansion plans – be that geographical or other. It will be an important exercise for a TPP to map out the integration points needed to fulfil its targets.
4. Working out how to connect to merchants
While the processes for identification and authentication between TPPs and ASPSPs leave a lot of unanswered questions, at least there are some elements in place as defined through the Regulatory Technical Standards (RTS). However, if the aspiring TPP wants to provide its services to e.g. a merchant that does not plan to be a TPP itself, how does the TPP go about handling this integration?
5. Offering the right security precautions
According to Article 97 of PSD2: “Member States shall ensure that a payment service provider applies strong customer authentication where the payer: (a) accesses its payment online; (b) initiates an electronic payment transaction; (c) carries out any action through a remote channel which may imply a risk of payment fraud or other abuses.” This means that all TPPs and banks must enable customers who are performing a payment to use two-factor authentication solutions.
Any good business needs to be prepared for success. But with PSD2 and TPPs accessing the banks’ systems via APIs, banks also need to prepare for successful TPPs – and even for TPPs that by mistake (or by design) generates high load on the APIs. Stress testing the systems can be very helpful to avoid accidental overload of the APIs.
The main challenge for you, when targeting the TPP role following PSD2, is to avoid much of the complex and evolving legislation to concentrate on developing the innovative services enabled by PSD2. The whitepaper ‘Time to get practical – a PSD2 whitepaper with a step-by-step preparation guide for Third Party Providers (TPPs)‘ provides more information on the right strategy for market players who consider the step to become a TPP.