PSD2 - Let the Games Begin
Payment Service Directive 2
Next month, the Payment Service Directive 2 (PSD2) by the European Commission enters into force. In addition, the European Commission and the European Banking Association (EBA) published the new Regulatory Technical Standards (RTS), which – after it has been approved by the European Parliament and the European Commission - has to be implemented by September 2019. How do the PSD2 and RTS impact a bank's product portfolio and where will they change the current rules of the game in the payments and cash management market?
On 13 January 2018, the PSD2 officially enters into force in the member states of the European Union. The European Economic Area countries follow with a delay of nine months. There are still many different interpretations of the PSD2. These range from a complete denial in terms of relevance up to a doom and gloom perspective on one’s bank business model. Which one is the more realistic view and what is important to consider in order to understand the PSD2?
More than just "Open Banking"
The PSD2 is viewed by many as an extension of the previous PSD with the additional requirement of the Open Banking interface for so-called Payment Initiation Service Provider (PISP) and Account Information Service Provider (AISP). This perception however does not fully grasp the PSD2 as it has several further objectives:
- Increased transparency for consumers
- Strengthened consumer rights
- Improved security for consumers
- Fostering innovation in the payment and cash management market
The PSD2 has extensive requirements with regards to fee transparency and information for consumers. The costs for a payment should be transparently disclosed and be easily understandable for bank customers. In doing so, the Commission indirectly expresses its displeasure with the current opacity in fee structures.
By requiring customers to confirm all fees before concluding a contract and after each transaction, the Commission aims at facilitating price comparisons between service providers and thus increasing market efficiency. Banks with complex fee structures are therefore well advised to fundamentally rethink their pricing models. Another issue is the strengthening of consumer rights. With the PSD2, comprehensive obligations for risk and fraud monitoring are imposed on banks. In addition, payment service providers are ultimately liable in the event of fraud. If a customer denies having authorized a payment, the bank must be in the position to prove that it has authenticated the customer correctly, that the transaction has been properly processed and that there have not been any technical errors in their systems.
Concerning these liability and monitoring rules, the PSD2 makes no distinction between electronic and non-electronic payment channels. This means that payment orders, which are given in person or via phone, post, fax or email, must be similarly checked. While the PSD2 mandates strong client authentication (SCA) for orders over electronic and remote channels (e.g. email), a bank can choose a risk-based approach for traditional channels. This means that it can do without testing two independent identification features. However, in the case of fraud, it must compensate the customer for the wrongly paid amount.
Strong user authentication across all channels?
This raises the question as to whether banks should not apply SCA comprehensively across all channels. In doing so, a customer is authenticated by means of at least two independent identification features, which may be something the customer knows (e.g. password), something the customer has (e.g. token device), or something the customer is (e.g. biometric identification).
The rules on transparency, risk and fraud liability will come into force on 13 January 2018. They apply to all accounts that can be used for payment transactions, regardless of whether they belong to the retail, corporate or private customer business. The PSD2 does not differentiate between bank types.
Open interfaces nationwide from 2019
The PSD2 also includes rules that oblige banks to meet certain technical requirements:
- Generation of an "authentication code" based on strong customer authentication
- "Dynamic linking" of the authentication code with the amount and beneficiary of a transaction
- Requirements for the generation of personalized security features
- Comprehensive risk and fraud monitoring
- Creation of open interfaces for the transmission of payment orders and the retrieval of account information
These requirements are explained in detail in the RTS of the EBA. The RTS does not define the technical standards per se. Instead, it explains what the standards that the national and international standardization bodies create must fulfill. In principle, each bank is free which standards it wants to apply if they have been issued by a recognized body.
The RTS are complementary to the PSD2 and must be implemented by Payment Service Providers within 18 months of their entry into force. It is important to note that a shorter timetable applies to the provision of open interfaces, as banks must publish their specifications and provide a testing platform at least six months before the launch of the new interface. Again, the PSD2 makes no differentiation between different types of banks. The conditions apply to all banks with payment capable accounts.
Open interfaces as opportunities for banks
With open interfaces available, technology providers and third-party banks can initiate payment transactions and obtain account information. This is fundamentally changing multi-banking as we know it today. Instead of using e.g. SWIFT, it will now be possible to manage one’s accounts across various banks via open interfaces. Since transactions via the open interfaces must be offered at the same pricing as transactions through online banking, multi-banking will become massively cheaper and more attractive for internationally active companies and private individuals.
SWIFT is not the only intermediary affected by the new open interface competition. In addition to the free interfaces under the PSD2, banks could introduce fee-based interfaces, for example for debit card issuers. Instead of going through schemes such as Mastercard or Visa, authorization requests and payments could be initiated via direct API interfaces by the card issuer. The difference to the mandatory interface that a bank under the PSD2 must offer for so-called "card-issuing payment service providers" (CIPSP) and such a debit card interface is marginal.
These are just two examples where open interfaces can change the business model sustainably and not only posing threats to individual institutions. Open interfaces can also be used for a broader distribution of banking, credit and investment products.
Of course, there are also negative aspects. The competition between banks, financial intermediaries and technology providers will intensify. Also, customers will increasingly adopt traditional functions of banks themselves. Already today, many companies operate professional in-house banking, which hardly differs from the services offered by a traditional bank.
It therefore pays off to rethink and re-evaluate the product strategy and the product portfolio and to start adapting to a new world with various open API interfaces, regardless of the current business model applied.
This is an article by Dennis Flad and Damien Taets van Amerongen, co-workers of Arevos.