PSD2 stands for second payment standards directive, and was issued by the EU with the intent to open access to data and services previously only available to banks. In theory, PSD2 went into effect on January 13, and should provide a clear framework for implementation. The difference between theory and practice is small in theory, but big in practice.
PSD2 is defined in a set of documents published by the EU, which are to be subsequently implemented as legislation by parliaments in EU countries and enforced by regulating bodies. PSD2 will effectively force financial institutions active in the EU to open up data and functionality previously only available to them to other parties. ZDNet turned to the experts to discuss the specifics of PSD2.
Accenture advises banks, Fintechs and other industry players in devising strategies to take advantage of PSD2. Anupam Majumdar and Marcus van Dalen, lead of Accenture's Payments & Open Banking consulting practice in the Netherlands and analyst with Accenture Financial Services respectively, have long standing experience with PSD2. According to them:
"PSD2 will create the platform for non-banks to enter banking services (starting with payments) and offer more choice to customers. PSD2 aims to harmonize market competitiveness between banks and non-banks and create a level playing field in payments processing within the EU. While PSD2 mentions a number of articles to achieve this objective, perhaps the most interesting is the provision of access-to-account (X2A) services.
This introduces new actors in the payments value chain. PISP (payment initiation service providers) and AISP (account information service providers) will be new third-party providers (TPP) who will have the ability to initiate a transaction from a customer account maintained at the customer's bank, and retrieve transaction information from a bank account respectively."
The bank is referred to as the account servicing payment service provider (ASPSP), and needs to have customer consent to provide access to TPPs. Majumdar and van Dalen believe that "while these new TPPs have the potential to change the face of payments, incumbent banks are being forced to play the role of providing only balance sheet provision services and 'utility banking services'.
TPPs will be able to offer customers with a new channel for their payments and reporting need thus pushing incumbent banks towards a risk of disintermediation. A traditional bank with a banking license has to ensure it is able to allow access of its customer payment and account information to TPPs, but can also aim to become an AISP or a PISP itself and protect against this disintermediation risk."
Majumdar and van Dalen say fintech companies with a banking license (and also GAFAs, Telcos, and retailers) will look at TPP business models with renewed interest, since they will now have the opportunity to provide banking services, disrupt the typically expensive fees laid out by the global card schemes, and leverage increased customer data points offered via these solutions for cross/up-sell opportunities.
So are we set for banking nirvana? Well, maybe not so fast -- there's a number of gotchas there. To begin with, PSD2 is not really in effect yet. The reason is that the EU needs to issue a set of Regulatory Technical Standards (RTS) for PSD2 to be workable in practice, and this is where the complications start.
Although an initial RTS was published in November 2017, anyone expecting to see concrete technical specifications in it is in for disappointment. There is an 18 month grace period through which the technical aspects of PSD2 are supposed to be fledged out. But how much of that can we really expect, when the current RTS makes a point of being "technology and business-model neutral"?
RTS lets the market define its own technical interpretations to implement it. Majumdar and van Dalen think that:
"the aim of making PSD2 technology neutral is to boost innovation, but the flip side of this is that there will be no EU-wide solution, in contrast e.g. to CMA's Open Banking standard that defines data and security standards for financial APIs.
We have started seeing regional initiatives to develop standards for open access such as the Berlin Group initiative, CAPS initiative, Open banking standard. However, having market participants defining such standards may lead to creation of regional hubs and the risk of a fragmented market for open access. RTS could have been slightly prescriptive here by defining the meta-data required to define a standard.
A number of banks today haven't even taken the first steps towards RTS implementation due to the lack of technical guidance from EBA and other regulatory bodies. Relying on market participants, banks may desire to play the waiting game till there is a critical mass of using the market dictated standards. Lack of interoperability across this standards may lead to fragmentation and a more complex banking environment."
In other words, PSD2 is far from being a standard, and it seems unlikely that it will move to this direction. While this may be good news for integration providers, it means the introduction of real-world applications will be delayed, and there will be duplication of effort and all the complexities related to data integration.
Majumdar and van Dalen note that some banks are struggling to meet PSD2 compliancy and will need the time to do so, while others are taking advance of the delays to work on new business models or their strategic response. Research done in the first half of 2017 showed that relatively few banks were ready for PSD2: 38 percent were still assessing the impact, while only 9 percent were in the implementation stage.
Accenture defines four primary strategic options banks can choose to pursue in reaction to PSD2 - basically doing more then only being compliant, but turning this into a business opportunity.
But it gets even more complicated. Majumdar and van Dalen mention that TPPs can leverage increased customer data points for example to cross/up-sell, but is that really an option, or should it be? In article 66 of PSD2, it is stated that PISPs will "not use, access or store any data for purposes other than for the provision of the payment initiation service as explicitly requested by the payer".
Majumdar and van Dalen note that this regards the PISP, not the AISP, so the PISP only initiates the transaction. If a TPP wants to do analytics on the payment data, they should be classified as AISP. While this provision is presumably meant to protect consumers against unauthorized storage and processing of their data beyond the context of a specific transaction, how it can be implemented is not clear.
"There is still a lot of unclarity over how PISPs will be asked to purge the customer data. While ASPSPs will be liable for loss of data, we foresee the development of new processes which ASPSPs are likely to put in place (especially at the time of on-boarding a TPP) which will provide more control to the end customer.
TPPs and ASPSPs would very soon need to comply with GDPR. Under such a regulation, ASPSPs have to guarantee protection of client data to TPPs. The unfortunate story so far has been that while PSD2 and GDPR both address 'customer data protection,' these texts do not make any references to each other. We are hoping the regulators would be able to define further guidelines to address this in the coming period."
Another thorny issue is that of provision for calculating fraud rates in the context of PSD2. The EBA has defined guidelines for exemption from certain aspects of RTS based on transaction risk monitoring and analysis. If a PISP can show that the risk for a certain transaction is below some threshold, a different, more lightweight process can be followed.
But how does the fact that fraud in retail and beyond is to a large extent today countered by applying machine learning (ML) models affect this? As opposed to traditional, procedural rule-based systems, ML-based systems are very hard to document in terms of their inner workings.
Though it won't be the first time a black box is trusted to provide answers with far-reaching consequences, and there is no explicit reference to this in PSD2, this could lead to the indirect institutionalization of the black box approach.
Majumdar and van Dalen think that:
"From a perspective of safeguarding low fraud levels, the thresholds defined by EBA are quite robust -- quite clear in terms of what needs to be monitored with transaction thresholds defined. This will have implications for PISPs and merchant acquirers who perform transaction risk assessment especially in ecommerce. Fraud systems need to be adjusted and in certain cases overhauled.
Every ecommerce transaction will need to be monitored [to check] if the RTS is applicable. The biggest challenge here would be to ensure the end customer doesn't have a friction driven buying experience -- therefore PISPs and acquirers would have to make necessary adjustments to their fraud monitoring and risk capabilities to take action."
PSD2 seems like a mixed bag. On the one hand, it forces banks to let go of their stronghold of data and services, and this is meant to create competition and create opportunities for other players. For an industry that has been criticized as having really meaningfully innovated for the last time more than 50 years ago when introducing the ATM, this may provide a useful nudge.
Fintech is already one of the fastest growing industries, and opening up opportunities in this domain should encourage its growth even further. While PSD2 is only applicable in the EU, presumably similar to GDPR all financial institutions operating there will have to comply. As there are already Fintech companies that operate worldwide, their users should be able to benefit from the additional services they would be encouraged to provide, thus putting more pressure on the rest of the industry as well.
On the other hand, this blurring of boundaries between banks and non-banks can also have its dark sides. The question of whom you should trust with your data becomes even more pronounced when it comes to potentially very sensitive financial data.
The fact that PSD2 provides no guidelines as to how to ensure customer data protection for PISPs is not a good sign, so you should be very cautious about whom you authorize for your payments. Furthermore, the fact that GAFAs can, and will in all likelihood, become players in this domain should also raise concerns regarding their ability to leverage their existing massive amounts of data on consumers and combine them with financial data to reach new heights in profiling.
In addition, the fact that PSD2 includes the option to become exempt from its own provisions based on mechanisms that are hard, if not impossible, to audit also raises concerns. Regulation is said to always be one step behind the market. If market players are themselves also not able to always fully comprehend the outcome of ML models, and regulators are left even further behind, what kind of transparency and trust can we expect?
When asked for comment on this, spokespeople from Revolut, a fintech startup that recently applied for a banking license, noted that "provided that such ML technology is fully disclosed to the FCA as part of a firm's anti-money laundering policy and this has the requisite FCA approval, Revolut does not see that ML technologies with regard to fraud should cause any particular issues in this regard."
Last but not least, the fact that PSD2 is not a real technical standard will also have implications. Besides the integration Babel that will ensue, it is foreseeable that industry heavyweights will effectively dictate their terms with respect to technical specifications, thus leading to a fragmented landscape still dominated by a handful of players.