• Lisa Gutu, Head of Business Development at Salt Edge


• 03.07.2020 08:15 am
PSD2

PSD2 obliges ASPSPs including banks, e-wallets, prepaid cards and other companies that offer payment accounts to provide at least one channel for secure communication with third party providers (TPP). Even neobanks or e-money institutions, including their agents, have to provide such channels with sandbox environments published 6 months before going live (RTS, clause 21). The recent Open Banking Report created by Salt Edge shows that not all the financial institutions have managed to meet all the regulatory requirements.

Financial institutions can choose to provide an API and/or a Modified Customer Interface (MCI). In this article we’ll explore the basic requirements for a PSD2 compliant channel, implementation challenges, major benefits and opportunities for financial institutions.

What are the main PSD2 compliance components regardless of the chosen channel?

• Provide documentation and a sandbox environment for TPPs;
• Provide access to live environment for account information service providers (AISP), payment initiation service providers (PISP) and balance check (PIISP/CBPII);
• Identify TPPs by verifying their eIDAS certificates;
• Meet the SCA and dynamic linking requirements;
• Support via the PSD2 channel the same authentication methods available to end-customers in the existing mobile/web banking (including app-to-app redirection);
• Provide TPPs with onboarding and further support assistance; 
• Notify TPPs of any changes to the channel 3 months before the implementation date;
• Provide consent management functionality;
• Ensure highest level of security;

What are the major differences between channel implementations (API vs MCI)?

In case of MCI, the main implementation challenges are:

1. There is a need to provide a developer portal and notify TPPs on any updates related to MCI 3 months before adding any changes to the interface itself, as specified in Article 30.4 of RTS;
2. It’s hard to implement a consent management system, especially for 90-day access for AISP, as specified in Article 10 of RTS; 
3. It is challenging to set up via MCI a mechanism for confirmation of funds for PIISP, as specified in Article 35.4.c of RTS;
4. In case the ASPSP has a mobile application, it should support the app-to-app authentication flow, as specified in the latest EBA Opinion. MCI can support only embedded or decoupled authentication flows while cannot support authentication via biometrics;
5. From a security standpoint there are various whitespots for MCI implementation. It requires user credentials to be shared with TPPs for authentication purposes due the supported embedded or decoupled authentication flows only. Also, in case the ASPSP uses a vendor for the MCI implementation, the end user credentials can be also accessed by this third party, which acts as a proxy service.

More information on MCI interface is provided in this article.

API, on the other hand, is easier to implement with a guarantee that all the PSD2 requirements are fully met. The API implementation allows the financial institution to have a holistic and transparent overview on the TPPs’ activities at all times. Financial institutions can even provide a revoke consent functionality to their customers to ensure that the data is being shared only with those parties customers really need. Implementing the APIs allow the financial institution to start the digital transformation journey and promote other services offered by the ASPSP via API as well, creating new monetisation streams.

How much time does it normally take to implement a PSD2 compliant channel?

ASPSPs have 3 options to proceed with the PSD2 implementation, which depends on the size of the ASPSP, desired time to market and the overall strategy of the financial institution:

I. Work with a SaaS vendor

1. Time to market: 1-3 months;
2. Associated costs: set up fee [€10-60K] + yearly maintenance fee [€30-300K];
3. Examples of financial institutions: e-wallets, banks such as BBVA, Bankinter, Intesa Sanpaolo, Crypto.com, Ikano bank, OP Bank, Tide bank, GT Bank, Byblos bank;
4. Pros: 
   ◦ Minimal technical requirements during the integration process;
   ◦ Minimal maintenance, support required; 
5. Cons:
   ◦ No possibility to customise the API further on their own. There is a need to always involve the vendor;
   ◦ Issues with finding and choosing the right vendor with real tech and PSD2 compliance experience & knowledge and proof of work with other clients;

II. Work with a vendor that builds the solution on premise

1. Time to market: 6-18 months;
2. Associated costs: [€500K+ for set up and yearly licence fee for €100K+];
3. Examples of financial institutions: HSBC, Bank-Verlag Group, N26;
4. Pros: 
   ◦ Customisable solution controlled by the bank;
5. Cons:
   ◦ Requires a lot of resources during the integration process;
   ◦ Requires enormous resources for maintenance/support after going live;

III. Build in-house

1. Time to market: 12-24 months;
2. Associated costs: [€200K-1M on consulting, developers, compliance teams];
3. Examples of financial institutions: Erste Bank Group, Deutsche Bank, PayPal;
4. Pros:
   ◦ Customisable solution controlled by the bank;
5. Cons:
   ◦ Requires an in-depth understanding of PSD2 from regulatory and technical standpoints;
   ◦ Requires a lot of resources during the development process;
   ◦ Requires a lot of resources for maintenance/support after going live;

What are the major benefits and opportunities of PSD2 API implementation?

PSD2 opens a new era where each bank and eWallet can provide any service to third parties via an API channel. Depending on the financial institution’s strategy and core products, a range of premium APIs can be opened up to TPPs. We can already see such examples on the market, where banks provide identity checks, mortgage calculator, wealth management APIs, ordering branded cards via API, automated FX market orders and real time rates, corporate payouts, instant fund transfers confirmations, and many more. I do expect that many other APIs like instant loans, account opening will follow to rise. By providing custom and truly valuable products on the markets, allowing TPPs to distribute such offerings to their end-users, ensuring longevity and prosperity of banks in the new era of banking-as-a-service.

Even the basic PSD2 API implementation ensures customers loyalty for banks because the end-customer will remain a user of the bank while using other applications and services. Banks can also get inspired from such TPPs through fruitful collaboration and improve their own services and offerings.

Hence, building a good, reliable PSD2 channel for TPPs can help financial institutions in retaining customers and acquiring new distribution channels (via TPPs) for their own products, increasing the number of transactions that customers are doing on a day-by-day basis.

If you want to learn more about PSD2 challenges and opportunities, subscribe for Salt Edge free webinar here.