We all know by now that “XS2A” - access to payment accounts by third party providers (TPPs) - is going to happen in some shape or form under PSD2, but there is still considerable uncertainty. The transposition of PSD2 into national law is being delayed in twenty member states and while the Regulatory Technical Standards on Strong Customer Authentication (SCA) and Common and Secure Communication (RTS) have been finalised by the European Commission, political discussions are still ongoing. Many market actors remain uncertain regarding compliance requirements and shifting implementation timelines.
Situation: Market expectations for XS2A might be overestimated
Banks are challenged to offer a communication interface that is compliant with PSD2 and the RTS. While banks could reuse their existing online banking interface with TPP identification and allow for a more “secure” form of “screen scraping”, we see that most banks opt for implementing Application Programming Interfaces (APIs) to realise XS2A compliance.
The design of these PSD2/RTS compliant APIs, like any compliance effort, has triggered various (legal, functional and technical) debates on the interpretations of what are the minimal requirements. The European Commission has set-up an API Evaluation Group - following the ERPB recommendations - that is tasked to shed more light on this matter in the coming months (first results expected in June 2018).
With the dust now settling more and more, we see a situation emerging where market expectations regarding the innovation possibilities of XS2A could be overestimated by market actors. Three topics that contribute to this possible “gap” between expectations and reality are: 1) functional scope of access, 2) interaction model between bank, customer and TPPs and 3) innovative information services by TPPs. The figure below provides a brief overview per topic and some relevant actions to consider.
Figure 1: Topic description and relevant actions
Topic 1: Functional scope of access
To enable the mandatory PSD2 services (PIS, AIS and CAF), banks designing APIs are likely to implement the bare minimum payment functionality and information that can be accessed from online accessible payment accounts. Other account types, functionality or information (incl. format in which it is available) will most likely not be made available via APIs as part of the bank’s compliance efforts. This richer functional scope of access is likely to be part of a commercial Open Banking strategy, for those banks that seek to open-up further than they are required by PSD2.
We observe that banks are overwhelmed by API designs and specifications. Numerous API standardisation initiatives emerged for PSD2 (Berlin Group, STET, UK/CMA, Polish API, Slovak API) requiring banks to make a strategic decision on participation in said initiatives. Banks need to be mindful of the considerations and trade-off decisions regarding API functionality to ensure XS2A compliance.
Topic 2: Interaction model between bank, customer and third party
Banks across Europe also have varying interpretations regarding the interaction model(s) they are required to support to enable XS2A. These interaction models (e.g. redirecting the customer to their own online channels and using their own issued credentials, an embedded model where the customer shares its credential with a TPP, or a tokenized model) directly affect integration possibilities and user experience from the perspective of a TPP.
The final RTS (art. 32.3) states that “imposing redirection” of the customer from the TPP to the bank’s authentication or other functions may be an obstacle. What might also be considered an obstacle is preventing TPPs to use the customer’s bank issued credentials. Without clear guidance and rules from law makers and no option to require any additional contracts under PSD2, banks predominantly seem to prefer to exclusively trust their own issued credentials and only in their own online channels. Anything else introduces risks for banks that cannot effectively be mitigated. Banks are faced with a key decision regarding selection of a compliant interaction model and with that the customer journey and experience they seek to enable for their customers when interacting with a TPP.
Topic 3: Innovative information services based on XS2A
There are different degrees of added value that a TPP can offer its customers based on access to their data, ranging from aggregating “raw account data” in the service to its customers, to offering services based on aggregated and enriched customer data, e.g. credit scoring, credit worthiness assessments and personalised service offerings.
However, two issues arise as TPPs process financial data. First, the more we deviate from “raw account data”, the more questions arise whether these activities are part of the scope of PSD2, and if these activities will be in scope for TPP licenses. National Competent Authorities seem to differ in their interpretation of the scope that is allowed for account information services. Another limitation in the use of such data may arise from another European regulation that will come into force in May 2018: all processing of personal data is subject to the General Data Protection Regulation (GDPR). All data processing by TPPs beyond the scope of PSD2 would require additional explicit consent.
Conclusion: The synergy between PSD2 XS2A and Open Banking
PSD2, and the concept of XS2A in particular, can be viewed as an important catalyst to accelerate change in payments, innovative banking applications and respective business models by leveraging payment functionality and account information. However, PSD2 XS2A does not fully cater for a context for such change and might therefore not deliver on heightened expectations of market actors.
The step to Open Banking, however, could overcome most of the limitations mentioned above. Banks can, on their own terms, offer more functionality and information rich services in different interaction models and design shared responsibility models for meeting GDPR requirements. This would result in more value add and a better customer experience. To enable such services, (bilateral) contracts between banks and partners can be put in place with agreement on risk and liability partition and revenue models. By addressing and overcoming PSD2 XS2A’s imperfections, a more open banking landscape is expected to deliver on the heightened expectations for digital transaction services and offer new value and experiences to customers. Where PSD2 XS2A compliance only forms a first step, Open Banking can actually deliver on its promise.
In our next blog we will provide more insight in the implications and decision options for banks to effectively deal with the topics elabored in this blog. In the intermediate, reach out to INNOPAY’s PSD2 and Open Banking specialists to understand more about XS2A and Open Banking and your options to move forward.