Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
1. Behavioural data as standalone inherence element
We as Klarna disagree with the view expressed by EBA in the recitals 29 of the EBA Draft RTS that behavioural data cannot be considered as a standalone inherence element. In our view, behavioural data should absolutely be recognised as standalone inherence element.
We have applied behavioural data to some of our online payment solutions for the last 11 years as an inherence element and have been able to achieve fraud levels that are lower than what the card networks publish for card transactions. The fraud levels are outlined below.
0,037% for Klarna online transactions
0,150% for card not present transactions
0,040% for card present transactions
Please find the reference on page five in the following link: https://www.visaeurope.com/media/pdf/visa%20mrc%20fraud%20guide%20-%20generic%20version.pdf
EBA current view is not taking Art 98 (2d) PSD2 into account.
According to Art 98 (2d) PSD2 the RTS shall be developed in order to ensure technology and business model neutrality.
EBA current view is not taking Art 98 (2e) PSD2 into account.
Not allowing behavioural data to be regarded as a standalone element of inherence also disregards Art 98 (2e) PSD2 according to which the RTS shall allow for the development of innovative, user friendly and reliable means of payment. The application of behavioural data for inherence purposes has served exactly that objective.
Behavioural data as a standalone inherence element should ensure an appropriate risk level.
We agree, however, that when allowing behavioural data to be a standalone inherence element it needs (in line with Art 98 (2a) PSD2) to ensure an appropriate level of security for payment service users and payment service providers, through the adoption of effective and risk-based requirements. Therefore, we are of the opinion that the use of behavioural data as standalone inherence element should only be permitted if it achieves at least the same risk level which can be achieved by the currently proposed elements. If it can be demonstrated that by leveraging behavioural data as a standalone inherence element will yield lower or the same results in fraud level than using the static definitions of the SCA elements, it should not only be allowed, but also encouraged.
In order to allow for behavioural data to qualify as inherence element, we therefore propose to amend the current wording in a way that the references to devices and software are removed, while at the same time keeping the risk level expressed in Art 5 EBA Draft RTS.
We would therefore propose to amend Art 5 of the EBA Draft RTS as follows:
“Art 5 Requirements related to elements categorised as inherence
1. The elements of strong customer authentication categorised as inherence shall be characterised by security features including, but not limited to, algorithm specifications, biometric sensor and template protection features ensuring resistance against the risk of sensitive information related to the elements being disclosed to unauthorised parties. These security features shall also guarantee a sufficiently low likelihood of an unauthorised party being authenticated as the legitimate payment service user.
2. The use of elements categorised as inherence shall be subject to measures ensuring that, if devices and the software is provided to the payer, they guarantee resistance against unauthorised use of the elements through access to the devices and software.”
2. Authentication Code and SCA in relation to e-mandates
The reasoning behind the authentication code to be created as a result of the authentication procedure (Art 1.1 of the EBA Draft RTS) is unclear to us. This does especially apply if one would follow the very broad interpretation of Art 97 (1c) PSD2 which EBA seems to pursue. In our understanding, it is not in scope for the RTS mandate to define when Art 97 (1c) PSD2 would apply and when not, but we would still want to comment on EBA’s view that the creation of e-mandates for direct debit would require SCA if a payment service provider is involved (recitals 18 EBA Draft RTS).
In our view, this interpretation is not correct to begin with. Direct debit is an important payment method used in many countries due to its easy availability. The PSD2 itself already provides sufficient measures to protect the payer by allowing an eight weeks refund period even for authorised transactions. This means that the payer is already sufficiently protected by the PSD2 and does not perform an action implying the risk for payment fraud as requested by Art 97 (1c) PSD2. The risk is rather on the side of the payee, which is, however, not the addressee of Art 97 (1c) PSD2.
If, following the current reasoning of EBA, SCA would need to be conducted in the form described in the RTS when signing e-mandates, the creation of an authentication code would not fit to such e-mandate sign up process nor add any additional security. For the PSP supporting merchants in setting up mandates, it is sufficient if the PSP has identified the person sufficiently. Sending a code to this person seems not to add any additional value as it would always be provided through the channels used for the identification already. If the authentication code shall imply that the ASPSP of the payer always needs to be involved in the signup of e-mandates (in this situation, the authentication code would make more sense), this is not in line with the practical circumstances. Even though there are some countries where ASPSP’s offer the possibility to their payers to create e-mandates online, this is not the case for all countries affected by the RTS. If one would request the ASPSP to be involved in the mandate signup process, this would make it impossible to use direct debit in countries where ASPSP’s do not provide such online signup process, which is likely not the intention of the RTS. Also, this understanding would not be in line with the intention behind the product, to provide the payee with a payment method where it is the payee triggering the payment and thus, not necessarily has to take place with the ASPSP being involved from the start. Furthermore, under the eIDAS we will see that new identification features will be developed. There is no reason why they should not be used for the sign-up for e-mandates as well.
Apart from what is mentioned above we see some potential risk of not ensuring fair competition as set out under Art 98 (2c) PSD2 under current draft. Art 1.3 (eiii) EBA Draft RTS requires “an adequate transaction history of the payer to evaluate its typical spending behavioural patterns”. This requirement can not be fulfilled for a new payment service user that has no history to take into consideration. In turn this creates an unfair bias in the market towards the largest market participants with the highest number of existing customers away from new entrants with a higher percentage new customers with a shorter or even non-existing transaction histories.
In recital 54 of the EBA draft RTS, EBA develops their reasoning around transaction-risk analysis and recognises the merit in the arguments. In addition we would like to highlight the requirements according to Art 98 (2e) PSD2 “allow for the development of user-friendly, accessible and innovative means of payment”; as well as the Art 98 (3a) PSD2 “the level of risk involved in the service provided”. EBA especially highlights the challenge of ensuring fair competition among all payment service providers as well as develop the minimum set of information the RTS should require for transaction risk-analysis to fulfill in order to be exempt from SCA.
While we recognise the challenge as described by EBA, we also view the current proposal as a massive inhibitor for innovation. Innovations which could readily satisfy a lower level of risk involved while at the same time ensuring a user friendly interface.
Most EU citizens will potentially use a number of different payment service providers on a regular basis, but most EU citizens will likely only have contact with one, or a very limited number of ASPSP’s. The ASPSP also bears most of the reputational risk and financial risk associated with fraud or abuse on the customer accounts as well as has the direct insight into the level of fraud and abuse currently on their accounts.
Our proposal would therefore be, to allow for exemptions based on transaction-risk analysis performed by the ASPSP. This would also be in line with Recital 41 of the EBA Draft RTS. However, in order to comply with the nondiscrimination requirements in Art 66 (4c) and 67 (3b) of PSD2, such exemptions should never be allowed to be applied to discriminate between PSPs. It should be a binary decision of the ASPSP to apply SCA or not for their account customers, independent of what PSP processes the specific transaction, however assuming that the ASPS assesses that the low levels of risk requirements is met with the technology they adopt. This satisfies fair competition among all payment service providers while still allowing for innovation in the market that will serve the consumers better.
Instead of proposing a minimum set of information for transaction-risk analysis, we would propose to implement a review process similar to the one described in Art 7 of the EBA Draft RTS in which the ASPSP should be obliged to prove in an authority review that such transaction risk analysis leads to lower levels of risk then under application of SCA.
We would therefore propose to add a new section as Art 8.3 RTS with a content similar to the following:
“In addition to the exemptions from the application of strong customer authentication described in Art 8.1 and 8.2 above, account servicing payment service providers (ASPSP) can decide not to apply strong customer authentication in accordance with Article 97 (1) or (2) of Directive (EU) 2015/2366 under the following conditions:
the ASPSP has transaction-risk analysis or other measures in place which ensure a risk level which is lower than when performing SCA; and
those measures are based on a binary decision equally applied in all cases where SCA would be required under Article 97 (1) or (2) irrespective if and which other payment service provider is involved in addition to the ASPSP.
With regard to those measures and the equal treatment, Art 7 of these RTS shall apply accordingly.”
Aside from what is mentioned above, we see the potential risk of some inconsistencies in the current RTS that we believe can be worthwhile to address.
When again taking the very broad interpretation of Art 97 (1c) PSD2 by EBA into account, the scope of the exemptions provided for such payment methods under Art 8.1 of the EBA Draft RTS seems to be unjustifiably limited in scope, compared to the exceptions provided under Art 8.2 of the EBA Draft RTS. It is our interpretation of the RTS that in the cases of Art 8.2 of the EBA Draft RTS (applicable for Art 97 (1b) PSD2) not only the dynamic linking would be exempted, but the complete SCA-process. Insofar, we see no reasons why e.g. an e-mandate sign-up process for direct debits of amounts under ten EUR should be treated differently than a credit transfer of an according amount. For the payment service user, the credit transfer of such amount would even be more risky compared to the direct debit mandate, where a refund can be requested within eight weeks even for authorised transactions. The same reasoning also applies to the other exceptions provided only for Art 97 (1b), but not Art 97 (1c) PSD2.
Further, in the exemption under Art 8.2 d) of the EBA Draft RTS, the amounts should be aligned with the amounts listed in Art 3 (1) PSD2. Otherwise, such providers of electronic communication networks would have an unjustified competitive advantage compared to payment service providers. This, however, would assume that the ASPSP can prove that a similar level of risk applies to such transactions as to transactions under Art 3 (1) PSD2.
We do not believe PSD2 intended such, per recital 33, “this Directive should aim to ensure continuity in the market, enabling existing and new service providers, regardless of business model”. Existing PIS providers operate today, “by establishing a software bridge between the website of the merchant and the online banking platform of the payer’s ASPSP (recital 27 PSD2)”, and are based on “direct and indirect access (recital 32 PSD2)”. Furthermore recital 93 PSD2 asserts the PIS must not be required by the ASPSP to use a particular business model, wheather based on direct or indirect access. As Art 66 of the PSD2 protects the consumer's right to make use of the PIS, we believe Chapter 4 of the EBA Draft RTS violates PSD2 by restricting the consumer's rights to use PIS via direct access.
Contrary to the PSD2 intentions as outlined in Art 98(2d), to ensure technology and business model neutrality, and EBA’s desire for non fragmentation per recital 5 of the EBA Draft RTS, dedicated interfaces will create a highly fragmented market across EU. Even within Member States there will be disadvantaged payment services users depending on who they are banking with. With the sole reliability on the ASPSP’s dedicated interface, which undoubtedly will be of varying quality, payment service users will be entirely dependent on the the infrastructure of the individual ASPSP’s.
It is a mistaken view of the ASPSP’s, that direct access would result in, “an inability to restrict access to specific data in compliance with data protection requirements, as AIS/PIS providers will have full access to information with no possibility to control what information is being accessed”, per recital 67 of the EBA Draft RTS. The overarching principles for protecting consumers personal details are already reflected in the GDPR, but in addition to that licensed PIS/AIS services will be subject to the data rules within Art 66 (2) and (3c) to (g) PSD2, which controls which information may be accessed. Therefore, there are no valid grounds for inserting a private intermediary, namely the ASPSP, between the payment service user and the PIS/AIS acting as an additional protection layer for personal data. This view would suggest that it is the ASPSP, not the consumer, who are in control of the data which is in direct conflict with European privacy regulations and the GDPR (below “A perspective beyond PSD2 on European Privacy regulations” outlines the reasoning).
Identification and Monitoring
It is an inaccurate statement per recital 64 of the Draft, that the main advantage of a dedicated interface is to control and track the access of AIS and PIS providers, as AIS and PIS access can be effectively controlled and monitored via direct access technology.
Art 66 of the PSD2 specifies the rules on access to payment account in the case of payment initiation services. Notability, Art 66 (3d) PSD2 states, “every time a payment is initiated, identify itself towards the account servicing payment service provider of the payer”. Due to the way direct access operates, we are confident such technology can satisfy this requirement without the need for a mandatory interface offered by the ASPSP.
The technical explanation of how direct access technology works is best explained by comparing the entry point with how a browser operates. When a payment service user enters their banking credentials in the user interface provided by the PIS/AIS the service then uses those credentials (but does not store them) to directly access the web-portal of the ASPSP. When the PIS/AIS is directly accessing the web-portal of the ASPSP the connection is essentially an additional “virtual” browser that mimics a real life user. Based on the browser type that the PIS/AIS is accessing with, the ASPSP is able to identify that it is not the payment service user themselves who are entering, but a third party. A browser will always send a header and in the header there is a user agent field, e.g. Google Chrome will send Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.36 in the user agent field (http://webaim.org/blog/user-agent-string-history/). Even today the common practice is for PIS/AIS services to identifying themselves, so the ASPSP can always see who is accessing their system.
Art 66 (3f) of the PSD2 lays downs the rules for which information may be requested by the PIS: “The payment initiation service provider shall not request from the payment service user any data other than those necessary to provide the payment initiation service”. In addition to the controls noted within PSD2, the ASPSP’s can also monitor and track what the PIS/AIS is requesting once they are inside the online banking web-portal. This means that the ASPSPs can already today monitor exactly what information is being accessed on each session. Principally, ASPSP’s can also block certain “virtual” browsers - this is however not allowed from a competition standpoint, but it is technically possible even today.
Furthermore the PSD2 outlines sanctions for noncompliance under Art 68 (5); “the account servicing payment provider may deny an account information service provider or a payment initiation service provider access to a payment account for objectively justified and duly evidenced reasons relating to unauthorised or fraudulent access”. Thereby, not only does the PSD2 outline the strict rules on access but also offers swift remedies in the event of a breach.
Enforceability of Uptime
Klarna has serious concerns with the effective availability of a ASPSP mandated dedicated interface and subsequently how the PIS/AIS can rely on their services. Our main concern regards the interest and incentive that ASPSP’s may or may not have in providing and maintaining such interface. From a strategic and commercial point of view, ASPSP will have different interests in having and maintaining such interface, therefore, the EBA must consider how the RTS can guarantee the five nines" (99.999% availability) of such a dedicated interface.
The phrase in Art 19 (6) of the EBA Draft RTS reads that: “Account servicing payment service providers shall ensure that their communication interface is operating on the same level of service, including support, as the online platform made available to the payment service user when directly accessing its accounts online. (…)”, however we fear such statement is too vague by not specifying which situations it is referring to, and this inevitably creates for the AIS/PIS an unreasonable burden of proof to demonstrate that, for each specific situation, the dedicated interface of the ASPSP was not available. Also, the words “operating on the same level” would be subject to different interpretations and views on what that level should be. Also unclear is who will do the general monitoring regarding the dedicated interface availability and ensure it is being properly maintained according to the prescribed standards. Plus, it must be stressed that at a purely technical level, AIS/PIS can’t simply switch on and off between direct and indirect access in order to initiate a payment or access a payment account.
The AIS and PIS providers would have to resort to the competent authority (and to the Commission) and await for their judgment. To initiate such legal and administrative proceedings would be costly and resourceful - especially if we consider a scenario where the dedicated interface lacks quality and availability and this issue persists across a number of different ASPSPs and across different Member States. Meanwhile, the respective PIS and AIS businesses would be unable to function, or at least deliver quality services towards the consumers, and consequently, it would lead them out of business. To make AIS and PIS reliable on national authorities supervision and judgements is an approach that is not aligned with the spirit of PSD 2, and any business relying on the availability of such dedicated interface would be losing their payment service users from the moment that the service is down. The reality is that a payment service user who has unsuccessfully tried once or multiple times to login to their personal finance app or execute a transaction online, is unlikely to use the AIS or PIS service again. Reliability and the ability to innovate is crucial for fast moving digital financial services.
A Licensed Entity Subject to Auditing
Klarna would also like to take the opportunity to stress that AIS and PIS services under PSD2, will become regulated entities and subject to the supervision of national authorities. PSD2 has already set up strict rules to guarantee the security of the online ASPSP environment under Art 66. If the current draft RTS were to be adopted as they stand, it would seem that the regulator is not confident in the enforceability of PSD2. To delegate a private intermediary - in this case, the ASPSP’s - as the gatekeeper between the law and the licensed entities is a sign of lack of trust to the legislators and national authorities. PSD2 has mandated EBA to specify the requirements for secure communication under Art 98, therefore we are of the opinion that the EBA should define the requirements for possible standards, rather than defining a standard as such. ASPSP’s are neither legislators nor regulators and the RTS should not delegate the ASPSP’s the mandate to make an ex ante judgement regarding the capacity of a another regulated entity to comply with European legislation.
Klarna suggests that the EBA relies on national authorities to regulate, audit and enforce the requirements for PIS/AIS services. Further, the EBA can look to the model for TSPs adopted in the US and outline the guidelines for the national authorities to rely on when auditing its PIS/AIS services.
The Solution: A Dual Approach
Dedicated interfaces will be welcomed and used by AIS and PIS services - provided that they are technically superior to direct access, easy to implement, maintain, update and use. Subject to their availability, as discussed above, the AIS and PIS services need a an alternative way of reaching the required information to carry out their services. The EBA should adopt a dual solution, whereby a PIS can continue to “directly” access the necessary information to initiate a transaction in line with recitals 32, 69 and 93 of the PSD2, as well as make use of the indirect access provided by the ASPSP via a dedicated interface. The model of direct access that is used today and has been used in the last 12 years, creates better value for consumers and merchants. The PIS services enables the e-commerce eco-system providing a secure environment with the highest encryption and risk standards, therefore enjoing of much lower fraud rates than other payment methods, e.g. cards.
A Case Study: A Perspective on the Global Market
As an example, in Sweden a selected number of market leader banks came together to build an API for a credit transfer payments system called Swish Handel. This solution was driven by a strong commercial incentive and the banks clearly targeted the growing e-commerce market. Klarna integrated the Swish Handel solution in our checkout in March 2016. However, this bank led API system has never been fully functioning and in May of this year, it was shut down due to an ongoing technical malfunction that could not be resolved. It has recently been publicly communicated that this API service may be re-launched sometime next year. Timing is still unclear. Even with a strong business case and collective effort by the banks with merchants ready to use the Swish Handel service, the technical issues of this credit transfer API could not be resolved. In other words, even with a strong commercial incentive to deliver and maintain a stable, functioning API, the banks have been unable to deliver this to the market.
Another example are the HBCI/FinTS standards that were developed in Germany in 1999. All the banks in Germany came together to develop the HBCI/FinTS and agreed to use this as a “multibank standard”. However, for half of the banks HBCI/FinTS is not implemented in a way that it can be used for PIS purposes and there were several reasons (e.g. extra log-in, only B2B accounts have access to HBCI etc.), but it mainly comes down to the fact that all banks have different infrastructure and technical platforms. However, HBCI/FinTS was well implemented by a couple of banks, e.g. Saving bank and part of Peoples bank and SOFORT is actively using this standard. Although SOFORT is only using this standard for a few banks that have properly implemented HBCI/FinTS it represents around 50% of SOFORTS transactions today. Another example is one of the big direct banks in Germany, who asked SOFORT actively to switch back to the direct access via the online-banking, because HBCI/FinTS was implemented outside their fraud detection tools. So it goes to show that if a standard is implemented with the right parameters and is functioning in an optimal way PIS services will in fact use them. Further it shows, that some banks may in fact prefer the direct access technology because they lack the incentive to develop or maintain such a standard, or simply is not able to (e.g. as above case of Swish Handel).
In conclusion, a good dedicated interface will be used, but it can not be mandatory for four reasons:
The PSD2 protects the rights of the consumer to use PIS services as they operate today per Retical 27,32,33 and engraved within Art 66 PSD2.
Not all ASPSPs will be incentivised to develop or maintain the dedicated interface to appropriate standards. There will be no incentive for ASPSPs to offer a quality and well maintained dedicated interface detrimental to their own offerings (e.g. Giropay, EPS, MyBank, iDEAL). While Art 19 (6) of the EBA Draft RTS acknowledges a same level would be required, we do not believe this wording is specific enough to enable monitoring or enforcement.
ASPSPs have very different technical infrastructures, meaning that a standard that works well for one ASPSP can not be expected to work equally well for another ASPSP. This will create a highly fragmented market and consumers across EU will have a significantly different experience based on their ASPSPs dedicated interface solution.
It is costly for ASPSPs to develop and maintain a dedicated interface. A mandatory dedicated interface RTS can be an unsustainable financial burden in terms of outsourcing and technical platform restructuring.
Furthermore, direct access technology has successfully been adopted as a secure, trusted and innovative model in the US with examples of Plaid, PayWithMyBank and Yodlee. These household US names are providing money moving solutions (PIS) and enabling consumers with access and control over their financial information, leading to more informed and personalised decision making (AIS). The payments solutions enables faster speed to market and enhanced distribution and market uniformity in the e-commerce sector. In the US third-party technology service providers, or TSPs, are under statutory supervision. The Federal Financial Institutions Examination Council is conducting audits and examinations based on guidelines that outline the process, uniform principles and standards of all TSPs. A report of examinations (RoE) is made publically available to all chartered financial institutions and their clients. The RoE cover a wide variety of subjects, including management, acquisition and development activities, support and delivery, IT and disaster preparedness and business recovery planning.
If the final RTS stipulates that European companies will no longer have the opportunity of using direct access technology there will be significant consequences for European Fintech. Fintech in Europe will be behind the technology curve and it gives e.g. US companies a significant competitive advantage. A mandatory dedicated interface provided by ASPSPs will block any further innovation and give ASPSPs the role of a gatekeeper. If European fintechs want to compete against the global players, they must have the freedom to create and set up additional features and new services in line with objectives for the RTS to “allow for the development of innovative means of payment.” per Art 98 (2e) PSD2. As mentioned above, PIS and AIS services will use technically advanced and secure dedicated interfaces, but it should be a free choice and dependent on the quality of the technology provided.
Furthermore, to allow for competition in the internal markets, promoting innovative technologies remains a key objective. The PSD2 states that the RTS must maintain fair competition among all PSP’s under Art 98 (2c) PSD2, furthermore it is a fundamental principle under EU competition law per Art 101 and 102 TFEU, to ensure undertakings must not be afforded the possibility of eliminating competition in respect of a substantial part of the products in question. As confirmation of this point, It has been held by the German Federal Cartel Office (Germany), banks must not restrict the account holders rights to use a PIS that relies on the existing banking websites despite the existence of a dedicated interface. Consequently, consumer access via mandatory ASPSP interfaces contradicts PSD2 and violates EU competition law.
In addition to that the current RTS also allows for the ASPSPs to come up with different dedicated interfaces for PIS or AIS or with a dedicated interface for PIS, but not for AIS. This scenario would be detrimental to European innovation as a solution that combines the capabilities of an AIS and PIS will no longer to be able to operate in a proper way. Changing between the PIS and AIS functionality would potentially require the consumer to log-in again. Therefore, even today most AIS solutions also offer a PIS functionality, so if the RTS is adopted in its current form it will jeopardise the existing business of some PIS/AIS services.
A Perspective Beyond PSD2 on European Privacy Regulations
By restricting the consumer’s right to accessing and sharing their own data by mandating a dedicated interface in the draft RTS is effectively in conflict with some fundamental principles of privacy and personal data legislation.
From a privacy perspective, two fundamental rights are recognised:
Data ownership and control - Users (data subjects) shall have control of their own personal data, including right of access it etc.
Data portability - The user shall have the right to transmit his/her data to another controller without hindrance from the controller to which the personal data have been provided.
Already in the early days of data privacy as a regulated activity, putting people in control of their information was thought to be what mattered the most. All the way from the 1980 OECD guidelines to the EU e-Privacy directive and the General Data Protection Regulation (“GDPR”), consent has been a cornerstone across legal regimes and jurisdictions. And this for a purpose – putting people in control of their information. Commissioner Reding herself, during the journey for the EU data protection legislative reform did numerous times make it clear that the enhancement of people’s data privacy rights was top priority and the reason was that the Commission wanted individuals to be able to maintain control over their data. And – as Commissioner Reding pointed out – particularly important in the online world. Given the importance of creating the trust that will allow the digital economy to develop across the internal market, it is for instance now expressly stated in the GDPR, recital 7, that natural persons should have control of their own personal data. It’s furthermore prescribed that legal and practical certainty for natural persons, economic operators and public authorities should be enhanced.
Data ownership, often discussed in legal doctrine, refers to both the possession of and responsibility for information. Ownership implies power as well as control. The control of information includes not just the ability to access, create, modify, package, derive benefit from, sell or remove data, but also the right to assign these access privileges to others. Many modern service providers give people access to their own data in machine readable format to download and use as they see fit. Proponents of increased data portability point to numerous, significant benefits for users, service providers, the broader public and society. For users, perhaps the most important benefits are the ability to choose between different service providers, create backups of their most important data (like photographs, tax returns, and financial information) while reducing the danger of becoming locked-into a single service provider, especially in a world where service providers may change business models or discontinue products. An example of how the principle of data portability has been implemented in practice is the Google takeout tool (https://takeout.google.com/settings/takeout/). With Google takeout consumers are able to download, export and move their data across the various google apps, e.g. Gmail, Calendar, Photos, Google+. The underlying purpose and principle behind the Google takeout tool is that the consumer, not Google, is the owner of their personal data. With Google takeout, and as per the principle of data portability, the consumers should have the choice to move their proprietary data from one provider to another.
To further strengthen the control over the user’s own data, the user should also be allowed to receive personal data concerning him/her which the user has provided to the data controller. Data controllers (such as ASPSPs) should furthermore under the GDPR be encouraged to develop interoperable formats that enable data portability, to apply whenever the data has been provided to the data controller based on user consent or the data processing is necessary for the performance of a contract between the parties. This is derived from recital 68 to the GDPR that reads: “(...) in a structured, commonly used, machine-readable and interoperable format, and to transmit it to another controller. Data controllers should be encouraged to develop interoperable formats that enable data portability.” Therefore, it is encouraged that ASPSPs should develop a dedicated interface, however it should not be the only way for PIS/AIS services to access the necessary data to offer their services. If it becomes mandatory for PIS/AIS to use the dedicated interface offered by the ASPSPs there is a risk that not all the personal data that the consumer wish to share is available via the dedicated interface. In the scenario of a mandatory dedicated interface, the personal data would hence be controlled by the ASPSP, and not the consumer. Provided that it is transparent, informed and voluntary for the consumer what data they are agree to share with third parties, e.g. PIS/AIS services, (e.g. user friendly and easy to understand) the users should have the right to dispose over their data as they wish. According to Art 20 in the GDPR the user shall have the right to receive the personal data concerning him/her, and also the right to have the personal data transmitted directly from one controller to another, where technically feasible.
Based on the importance today of user trust – for the online world and elsewhere - it is inevitably important that the user rights are respected and strengthened and that the user remains in full control. Users need to be empowered for this to happen. PIS/AIS services are today exactly empowering the user with the access to their own data, e.g. AIS services are providing the user with a level of insight on their own spending patterns that they have not previously been able to get from their own ASPSP. AIS services can also help the user aggregate their financial information which often time will be scattered across several ASPSP providers. As a user, to be able to stay in control of the data in the user’s own bank account, to be able to choose how to use that data and with what other online service, to be able to transfer that data to another service provider at a point in time and in a way that the user so chooses, is an important cornerstone of the user rights, also in line with the fundamental data privacy considerations not to be undermined by other regulations."
Question 1: Do you agree with the EBA’s reasoning on the requirements of the strong customer authentication, and the resultant provisions proposed in Chapter 1 of the draft RTS?
Please find below Klarna AB (publ) comments on Chapter 1 of the Draft RTS:1. Behavioural data as standalone inherence element
We as Klarna disagree with the view expressed by EBA in the recitals 29 of the EBA Draft RTS that behavioural data cannot be considered as a standalone inherence element. In our view, behavioural data should absolutely be recognised as standalone inherence element.
We have applied behavioural data to some of our online payment solutions for the last 11 years as an inherence element and have been able to achieve fraud levels that are lower than what the card networks publish for card transactions. The fraud levels are outlined below.
0,037% for Klarna online transactions
0,150% for card not present transactions
0,040% for card present transactions
Please find the reference on page five in the following link: https://www.visaeurope.com/media/pdf/visa%20mrc%20fraud%20guide%20-%20generic%20version.pdf
EBA current view is not taking Art 98 (2d) PSD2 into account.
According to Art 98 (2d) PSD2 the RTS shall be developed in order to ensure technology and business model neutrality.
EBA current view is not taking Art 98 (2e) PSD2 into account.
Not allowing behavioural data to be regarded as a standalone element of inherence also disregards Art 98 (2e) PSD2 according to which the RTS shall allow for the development of innovative, user friendly and reliable means of payment. The application of behavioural data for inherence purposes has served exactly that objective.
Behavioural data as a standalone inherence element should ensure an appropriate risk level.
We agree, however, that when allowing behavioural data to be a standalone inherence element it needs (in line with Art 98 (2a) PSD2) to ensure an appropriate level of security for payment service users and payment service providers, through the adoption of effective and risk-based requirements. Therefore, we are of the opinion that the use of behavioural data as standalone inherence element should only be permitted if it achieves at least the same risk level which can be achieved by the currently proposed elements. If it can be demonstrated that by leveraging behavioural data as a standalone inherence element will yield lower or the same results in fraud level than using the static definitions of the SCA elements, it should not only be allowed, but also encouraged.
In order to allow for behavioural data to qualify as inherence element, we therefore propose to amend the current wording in a way that the references to devices and software are removed, while at the same time keeping the risk level expressed in Art 5 EBA Draft RTS.
We would therefore propose to amend Art 5 of the EBA Draft RTS as follows:
“Art 5 Requirements related to elements categorised as inherence
1. The elements of strong customer authentication categorised as inherence shall be characterised by security features including, but not limited to, algorithm specifications, biometric sensor and template protection features ensuring resistance against the risk of sensitive information related to the elements being disclosed to unauthorised parties. These security features shall also guarantee a sufficiently low likelihood of an unauthorised party being authenticated as the legitimate payment service user.
2. The use of elements categorised as inherence shall be subject to measures ensuring that, if devices and the software is provided to the payer, they guarantee resistance against unauthorised use of the elements through access to the devices and software.”
2. Authentication Code and SCA in relation to e-mandates
The reasoning behind the authentication code to be created as a result of the authentication procedure (Art 1.1 of the EBA Draft RTS) is unclear to us. This does especially apply if one would follow the very broad interpretation of Art 97 (1c) PSD2 which EBA seems to pursue. In our understanding, it is not in scope for the RTS mandate to define when Art 97 (1c) PSD2 would apply and when not, but we would still want to comment on EBA’s view that the creation of e-mandates for direct debit would require SCA if a payment service provider is involved (recitals 18 EBA Draft RTS).
In our view, this interpretation is not correct to begin with. Direct debit is an important payment method used in many countries due to its easy availability. The PSD2 itself already provides sufficient measures to protect the payer by allowing an eight weeks refund period even for authorised transactions. This means that the payer is already sufficiently protected by the PSD2 and does not perform an action implying the risk for payment fraud as requested by Art 97 (1c) PSD2. The risk is rather on the side of the payee, which is, however, not the addressee of Art 97 (1c) PSD2.
If, following the current reasoning of EBA, SCA would need to be conducted in the form described in the RTS when signing e-mandates, the creation of an authentication code would not fit to such e-mandate sign up process nor add any additional security. For the PSP supporting merchants in setting up mandates, it is sufficient if the PSP has identified the person sufficiently. Sending a code to this person seems not to add any additional value as it would always be provided through the channels used for the identification already. If the authentication code shall imply that the ASPSP of the payer always needs to be involved in the signup of e-mandates (in this situation, the authentication code would make more sense), this is not in line with the practical circumstances. Even though there are some countries where ASPSP’s offer the possibility to their payers to create e-mandates online, this is not the case for all countries affected by the RTS. If one would request the ASPSP to be involved in the mandate signup process, this would make it impossible to use direct debit in countries where ASPSP’s do not provide such online signup process, which is likely not the intention of the RTS. Also, this understanding would not be in line with the intention behind the product, to provide the payee with a payment method where it is the payee triggering the payment and thus, not necessarily has to take place with the ASPSP being involved from the start. Furthermore, under the eIDAS we will see that new identification features will be developed. There is no reason why they should not be used for the sign-up for e-mandates as well.
Apart from what is mentioned above we see some potential risk of not ensuring fair competition as set out under Art 98 (2c) PSD2 under current draft. Art 1.3 (eiii) EBA Draft RTS requires “an adequate transaction history of the payer to evaluate its typical spending behavioural patterns”. This requirement can not be fulfilled for a new payment service user that has no history to take into consideration. In turn this creates an unfair bias in the market towards the largest market participants with the highest number of existing customers away from new entrants with a higher percentage new customers with a shorter or even non-existing transaction histories.
Question 2: In particular, in relation to the “dynamic linking” procedure, do you agree with the EBA’s reasoning that the requirements should remain neutral as to when the “dynamic linking” should take place, under the conditions that the channel, mobile application, or device where the information about the amount and the payee of the transaction is displayed is independent or segregated from the channel, mobile application or device used for initiating the payment, as foreseen in Article 2.2 of the draft RTS.
N/AQuestion 3: In particular, in relation to the protection of authentication elements, are you aware of other threats than the ones identified in articles 3, 4 and 5 of the draft RTS against which authentication elements should be resistant?
N/AQuestion 4: Do you agree with the EBA’s reasoning on the exemptions from the application of Article 97 on strong customer authentication and on security measures, and the resultant provisions proposed in Chapter 2 of the draft RTS?
We partially agree with EBA’s reasoning, however, we think there is an opportunity to develop the provisions somewhat differently to even better satisfy all the in part conflicting requirements set on EBA by the PSD2.In recital 54 of the EBA draft RTS, EBA develops their reasoning around transaction-risk analysis and recognises the merit in the arguments. In addition we would like to highlight the requirements according to Art 98 (2e) PSD2 “allow for the development of user-friendly, accessible and innovative means of payment”; as well as the Art 98 (3a) PSD2 “the level of risk involved in the service provided”. EBA especially highlights the challenge of ensuring fair competition among all payment service providers as well as develop the minimum set of information the RTS should require for transaction risk-analysis to fulfill in order to be exempt from SCA.
While we recognise the challenge as described by EBA, we also view the current proposal as a massive inhibitor for innovation. Innovations which could readily satisfy a lower level of risk involved while at the same time ensuring a user friendly interface.
Most EU citizens will potentially use a number of different payment service providers on a regular basis, but most EU citizens will likely only have contact with one, or a very limited number of ASPSP’s. The ASPSP also bears most of the reputational risk and financial risk associated with fraud or abuse on the customer accounts as well as has the direct insight into the level of fraud and abuse currently on their accounts.
Our proposal would therefore be, to allow for exemptions based on transaction-risk analysis performed by the ASPSP. This would also be in line with Recital 41 of the EBA Draft RTS. However, in order to comply with the nondiscrimination requirements in Art 66 (4c) and 67 (3b) of PSD2, such exemptions should never be allowed to be applied to discriminate between PSPs. It should be a binary decision of the ASPSP to apply SCA or not for their account customers, independent of what PSP processes the specific transaction, however assuming that the ASPS assesses that the low levels of risk requirements is met with the technology they adopt. This satisfies fair competition among all payment service providers while still allowing for innovation in the market that will serve the consumers better.
Instead of proposing a minimum set of information for transaction-risk analysis, we would propose to implement a review process similar to the one described in Art 7 of the EBA Draft RTS in which the ASPSP should be obliged to prove in an authority review that such transaction risk analysis leads to lower levels of risk then under application of SCA.
We would therefore propose to add a new section as Art 8.3 RTS with a content similar to the following:
“In addition to the exemptions from the application of strong customer authentication described in Art 8.1 and 8.2 above, account servicing payment service providers (ASPSP) can decide not to apply strong customer authentication in accordance with Article 97 (1) or (2) of Directive (EU) 2015/2366 under the following conditions:
the ASPSP has transaction-risk analysis or other measures in place which ensure a risk level which is lower than when performing SCA; and
those measures are based on a binary decision equally applied in all cases where SCA would be required under Article 97 (1) or (2) irrespective if and which other payment service provider is involved in addition to the ASPSP.
With regard to those measures and the equal treatment, Art 7 of these RTS shall apply accordingly.”
Aside from what is mentioned above, we see the potential risk of some inconsistencies in the current RTS that we believe can be worthwhile to address.
When again taking the very broad interpretation of Art 97 (1c) PSD2 by EBA into account, the scope of the exemptions provided for such payment methods under Art 8.1 of the EBA Draft RTS seems to be unjustifiably limited in scope, compared to the exceptions provided under Art 8.2 of the EBA Draft RTS. It is our interpretation of the RTS that in the cases of Art 8.2 of the EBA Draft RTS (applicable for Art 97 (1b) PSD2) not only the dynamic linking would be exempted, but the complete SCA-process. Insofar, we see no reasons why e.g. an e-mandate sign-up process for direct debits of amounts under ten EUR should be treated differently than a credit transfer of an according amount. For the payment service user, the credit transfer of such amount would even be more risky compared to the direct debit mandate, where a refund can be requested within eight weeks even for authorised transactions. The same reasoning also applies to the other exceptions provided only for Art 97 (1b), but not Art 97 (1c) PSD2.
Further, in the exemption under Art 8.2 d) of the EBA Draft RTS, the amounts should be aligned with the amounts listed in Art 3 (1) PSD2. Otherwise, such providers of electronic communication networks would have an unjustified competitive advantage compared to payment service providers. This, however, would assume that the ASPSP can prove that a similar level of risk applies to such transactions as to transactions under Art 3 (1) PSD2.
Question 5: Do you have any concern with the list of exemptions contained in Chapter 2 of the draft RTS for the scenario that PSPs are prevented from implementing SCA on transactions that meet the criteria for exemption?
N/AQuestion 6: Do you agree with the EBA’s reasoning on the protection of the confidentiality and the integrity of the payment service users’ personalised security credentials, and the resultant provisions proposed in Chapter 3 of the draft RTS?
N/AQuestion 7: Do you agree with the EBA’s reasoning on the requirements for common and secure open standards of communication for the purpose of identification, authentication, notification, and information, and the resultant provisions proposed in Chapter 4 of the draft RTS?
The current RTS draft as it stands reads that the use of a “dedicated interface” must be mandatory for PIS/AIS if offered by the PSU ASPSP. We believe that the current wording does not reflect the legislators intentions in PSD2 regarding the principle of neutrality, level playing field and the objective of improving competition between market incumbents and new players for the following reasons:We do not believe PSD2 intended such, per recital 33, “this Directive should aim to ensure continuity in the market, enabling existing and new service providers, regardless of business model”. Existing PIS providers operate today, “by establishing a software bridge between the website of the merchant and the online banking platform of the payer’s ASPSP (recital 27 PSD2)”, and are based on “direct and indirect access (recital 32 PSD2)”. Furthermore recital 93 PSD2 asserts the PIS must not be required by the ASPSP to use a particular business model, wheather based on direct or indirect access. As Art 66 of the PSD2 protects the consumer's right to make use of the PIS, we believe Chapter 4 of the EBA Draft RTS violates PSD2 by restricting the consumer's rights to use PIS via direct access.
Contrary to the PSD2 intentions as outlined in Art 98(2d), to ensure technology and business model neutrality, and EBA’s desire for non fragmentation per recital 5 of the EBA Draft RTS, dedicated interfaces will create a highly fragmented market across EU. Even within Member States there will be disadvantaged payment services users depending on who they are banking with. With the sole reliability on the ASPSP’s dedicated interface, which undoubtedly will be of varying quality, payment service users will be entirely dependent on the the infrastructure of the individual ASPSP’s.
It is a mistaken view of the ASPSP’s, that direct access would result in, “an inability to restrict access to specific data in compliance with data protection requirements, as AIS/PIS providers will have full access to information with no possibility to control what information is being accessed”, per recital 67 of the EBA Draft RTS. The overarching principles for protecting consumers personal details are already reflected in the GDPR, but in addition to that licensed PIS/AIS services will be subject to the data rules within Art 66 (2) and (3c) to (g) PSD2, which controls which information may be accessed. Therefore, there are no valid grounds for inserting a private intermediary, namely the ASPSP, between the payment service user and the PIS/AIS acting as an additional protection layer for personal data. This view would suggest that it is the ASPSP, not the consumer, who are in control of the data which is in direct conflict with European privacy regulations and the GDPR (below “A perspective beyond PSD2 on European Privacy regulations” outlines the reasoning).
Identification and Monitoring
It is an inaccurate statement per recital 64 of the Draft, that the main advantage of a dedicated interface is to control and track the access of AIS and PIS providers, as AIS and PIS access can be effectively controlled and monitored via direct access technology.
Art 66 of the PSD2 specifies the rules on access to payment account in the case of payment initiation services. Notability, Art 66 (3d) PSD2 states, “every time a payment is initiated, identify itself towards the account servicing payment service provider of the payer”. Due to the way direct access operates, we are confident such technology can satisfy this requirement without the need for a mandatory interface offered by the ASPSP.
The technical explanation of how direct access technology works is best explained by comparing the entry point with how a browser operates. When a payment service user enters their banking credentials in the user interface provided by the PIS/AIS the service then uses those credentials (but does not store them) to directly access the web-portal of the ASPSP. When the PIS/AIS is directly accessing the web-portal of the ASPSP the connection is essentially an additional “virtual” browser that mimics a real life user. Based on the browser type that the PIS/AIS is accessing with, the ASPSP is able to identify that it is not the payment service user themselves who are entering, but a third party. A browser will always send a header and in the header there is a user agent field, e.g. Google Chrome will send Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.36 in the user agent field (http://webaim.org/blog/user-agent-string-history/). Even today the common practice is for PIS/AIS services to identifying themselves, so the ASPSP can always see who is accessing their system.
Art 66 (3f) of the PSD2 lays downs the rules for which information may be requested by the PIS: “The payment initiation service provider shall not request from the payment service user any data other than those necessary to provide the payment initiation service”. In addition to the controls noted within PSD2, the ASPSP’s can also monitor and track what the PIS/AIS is requesting once they are inside the online banking web-portal. This means that the ASPSPs can already today monitor exactly what information is being accessed on each session. Principally, ASPSP’s can also block certain “virtual” browsers - this is however not allowed from a competition standpoint, but it is technically possible even today.
Furthermore the PSD2 outlines sanctions for noncompliance under Art 68 (5); “the account servicing payment provider may deny an account information service provider or a payment initiation service provider access to a payment account for objectively justified and duly evidenced reasons relating to unauthorised or fraudulent access”. Thereby, not only does the PSD2 outline the strict rules on access but also offers swift remedies in the event of a breach.
Enforceability of Uptime
Klarna has serious concerns with the effective availability of a ASPSP mandated dedicated interface and subsequently how the PIS/AIS can rely on their services. Our main concern regards the interest and incentive that ASPSP’s may or may not have in providing and maintaining such interface. From a strategic and commercial point of view, ASPSP will have different interests in having and maintaining such interface, therefore, the EBA must consider how the RTS can guarantee the five nines" (99.999% availability) of such a dedicated interface.
The phrase in Art 19 (6) of the EBA Draft RTS reads that: “Account servicing payment service providers shall ensure that their communication interface is operating on the same level of service, including support, as the online platform made available to the payment service user when directly accessing its accounts online. (…)”, however we fear such statement is too vague by not specifying which situations it is referring to, and this inevitably creates for the AIS/PIS an unreasonable burden of proof to demonstrate that, for each specific situation, the dedicated interface of the ASPSP was not available. Also, the words “operating on the same level” would be subject to different interpretations and views on what that level should be. Also unclear is who will do the general monitoring regarding the dedicated interface availability and ensure it is being properly maintained according to the prescribed standards. Plus, it must be stressed that at a purely technical level, AIS/PIS can’t simply switch on and off between direct and indirect access in order to initiate a payment or access a payment account.
The AIS and PIS providers would have to resort to the competent authority (and to the Commission) and await for their judgment. To initiate such legal and administrative proceedings would be costly and resourceful - especially if we consider a scenario where the dedicated interface lacks quality and availability and this issue persists across a number of different ASPSPs and across different Member States. Meanwhile, the respective PIS and AIS businesses would be unable to function, or at least deliver quality services towards the consumers, and consequently, it would lead them out of business. To make AIS and PIS reliable on national authorities supervision and judgements is an approach that is not aligned with the spirit of PSD 2, and any business relying on the availability of such dedicated interface would be losing their payment service users from the moment that the service is down. The reality is that a payment service user who has unsuccessfully tried once or multiple times to login to their personal finance app or execute a transaction online, is unlikely to use the AIS or PIS service again. Reliability and the ability to innovate is crucial for fast moving digital financial services.
A Licensed Entity Subject to Auditing
Klarna would also like to take the opportunity to stress that AIS and PIS services under PSD2, will become regulated entities and subject to the supervision of national authorities. PSD2 has already set up strict rules to guarantee the security of the online ASPSP environment under Art 66. If the current draft RTS were to be adopted as they stand, it would seem that the regulator is not confident in the enforceability of PSD2. To delegate a private intermediary - in this case, the ASPSP’s - as the gatekeeper between the law and the licensed entities is a sign of lack of trust to the legislators and national authorities. PSD2 has mandated EBA to specify the requirements for secure communication under Art 98, therefore we are of the opinion that the EBA should define the requirements for possible standards, rather than defining a standard as such. ASPSP’s are neither legislators nor regulators and the RTS should not delegate the ASPSP’s the mandate to make an ex ante judgement regarding the capacity of a another regulated entity to comply with European legislation.
Klarna suggests that the EBA relies on national authorities to regulate, audit and enforce the requirements for PIS/AIS services. Further, the EBA can look to the model for TSPs adopted in the US and outline the guidelines for the national authorities to rely on when auditing its PIS/AIS services.
The Solution: A Dual Approach
Dedicated interfaces will be welcomed and used by AIS and PIS services - provided that they are technically superior to direct access, easy to implement, maintain, update and use. Subject to their availability, as discussed above, the AIS and PIS services need a an alternative way of reaching the required information to carry out their services. The EBA should adopt a dual solution, whereby a PIS can continue to “directly” access the necessary information to initiate a transaction in line with recitals 32, 69 and 93 of the PSD2, as well as make use of the indirect access provided by the ASPSP via a dedicated interface. The model of direct access that is used today and has been used in the last 12 years, creates better value for consumers and merchants. The PIS services enables the e-commerce eco-system providing a secure environment with the highest encryption and risk standards, therefore enjoing of much lower fraud rates than other payment methods, e.g. cards.
A Case Study: A Perspective on the Global Market
As an example, in Sweden a selected number of market leader banks came together to build an API for a credit transfer payments system called Swish Handel. This solution was driven by a strong commercial incentive and the banks clearly targeted the growing e-commerce market. Klarna integrated the Swish Handel solution in our checkout in March 2016. However, this bank led API system has never been fully functioning and in May of this year, it was shut down due to an ongoing technical malfunction that could not be resolved. It has recently been publicly communicated that this API service may be re-launched sometime next year. Timing is still unclear. Even with a strong business case and collective effort by the banks with merchants ready to use the Swish Handel service, the technical issues of this credit transfer API could not be resolved. In other words, even with a strong commercial incentive to deliver and maintain a stable, functioning API, the banks have been unable to deliver this to the market.
Another example are the HBCI/FinTS standards that were developed in Germany in 1999. All the banks in Germany came together to develop the HBCI/FinTS and agreed to use this as a “multibank standard”. However, for half of the banks HBCI/FinTS is not implemented in a way that it can be used for PIS purposes and there were several reasons (e.g. extra log-in, only B2B accounts have access to HBCI etc.), but it mainly comes down to the fact that all banks have different infrastructure and technical platforms. However, HBCI/FinTS was well implemented by a couple of banks, e.g. Saving bank and part of Peoples bank and SOFORT is actively using this standard. Although SOFORT is only using this standard for a few banks that have properly implemented HBCI/FinTS it represents around 50% of SOFORTS transactions today. Another example is one of the big direct banks in Germany, who asked SOFORT actively to switch back to the direct access via the online-banking, because HBCI/FinTS was implemented outside their fraud detection tools. So it goes to show that if a standard is implemented with the right parameters and is functioning in an optimal way PIS services will in fact use them. Further it shows, that some banks may in fact prefer the direct access technology because they lack the incentive to develop or maintain such a standard, or simply is not able to (e.g. as above case of Swish Handel).
In conclusion, a good dedicated interface will be used, but it can not be mandatory for four reasons:
The PSD2 protects the rights of the consumer to use PIS services as they operate today per Retical 27,32,33 and engraved within Art 66 PSD2.
Not all ASPSPs will be incentivised to develop or maintain the dedicated interface to appropriate standards. There will be no incentive for ASPSPs to offer a quality and well maintained dedicated interface detrimental to their own offerings (e.g. Giropay, EPS, MyBank, iDEAL). While Art 19 (6) of the EBA Draft RTS acknowledges a same level would be required, we do not believe this wording is specific enough to enable monitoring or enforcement.
ASPSPs have very different technical infrastructures, meaning that a standard that works well for one ASPSP can not be expected to work equally well for another ASPSP. This will create a highly fragmented market and consumers across EU will have a significantly different experience based on their ASPSPs dedicated interface solution.
It is costly for ASPSPs to develop and maintain a dedicated interface. A mandatory dedicated interface RTS can be an unsustainable financial burden in terms of outsourcing and technical platform restructuring.
Furthermore, direct access technology has successfully been adopted as a secure, trusted and innovative model in the US with examples of Plaid, PayWithMyBank and Yodlee. These household US names are providing money moving solutions (PIS) and enabling consumers with access and control over their financial information, leading to more informed and personalised decision making (AIS). The payments solutions enables faster speed to market and enhanced distribution and market uniformity in the e-commerce sector. In the US third-party technology service providers, or TSPs, are under statutory supervision. The Federal Financial Institutions Examination Council is conducting audits and examinations based on guidelines that outline the process, uniform principles and standards of all TSPs. A report of examinations (RoE) is made publically available to all chartered financial institutions and their clients. The RoE cover a wide variety of subjects, including management, acquisition and development activities, support and delivery, IT and disaster preparedness and business recovery planning.
If the final RTS stipulates that European companies will no longer have the opportunity of using direct access technology there will be significant consequences for European Fintech. Fintech in Europe will be behind the technology curve and it gives e.g. US companies a significant competitive advantage. A mandatory dedicated interface provided by ASPSPs will block any further innovation and give ASPSPs the role of a gatekeeper. If European fintechs want to compete against the global players, they must have the freedom to create and set up additional features and new services in line with objectives for the RTS to “allow for the development of innovative means of payment.” per Art 98 (2e) PSD2. As mentioned above, PIS and AIS services will use technically advanced and secure dedicated interfaces, but it should be a free choice and dependent on the quality of the technology provided.
Furthermore, to allow for competition in the internal markets, promoting innovative technologies remains a key objective. The PSD2 states that the RTS must maintain fair competition among all PSP’s under Art 98 (2c) PSD2, furthermore it is a fundamental principle under EU competition law per Art 101 and 102 TFEU, to ensure undertakings must not be afforded the possibility of eliminating competition in respect of a substantial part of the products in question. As confirmation of this point, It has been held by the German Federal Cartel Office (Germany), banks must not restrict the account holders rights to use a PIS that relies on the existing banking websites despite the existence of a dedicated interface. Consequently, consumer access via mandatory ASPSP interfaces contradicts PSD2 and violates EU competition law.
In addition to that the current RTS also allows for the ASPSPs to come up with different dedicated interfaces for PIS or AIS or with a dedicated interface for PIS, but not for AIS. This scenario would be detrimental to European innovation as a solution that combines the capabilities of an AIS and PIS will no longer to be able to operate in a proper way. Changing between the PIS and AIS functionality would potentially require the consumer to log-in again. Therefore, even today most AIS solutions also offer a PIS functionality, so if the RTS is adopted in its current form it will jeopardise the existing business of some PIS/AIS services.
A Perspective Beyond PSD2 on European Privacy Regulations
By restricting the consumer’s right to accessing and sharing their own data by mandating a dedicated interface in the draft RTS is effectively in conflict with some fundamental principles of privacy and personal data legislation.
From a privacy perspective, two fundamental rights are recognised:
Data ownership and control - Users (data subjects) shall have control of their own personal data, including right of access it etc.
Data portability - The user shall have the right to transmit his/her data to another controller without hindrance from the controller to which the personal data have been provided.
Already in the early days of data privacy as a regulated activity, putting people in control of their information was thought to be what mattered the most. All the way from the 1980 OECD guidelines to the EU e-Privacy directive and the General Data Protection Regulation (“GDPR”), consent has been a cornerstone across legal regimes and jurisdictions. And this for a purpose – putting people in control of their information. Commissioner Reding herself, during the journey for the EU data protection legislative reform did numerous times make it clear that the enhancement of people’s data privacy rights was top priority and the reason was that the Commission wanted individuals to be able to maintain control over their data. And – as Commissioner Reding pointed out – particularly important in the online world. Given the importance of creating the trust that will allow the digital economy to develop across the internal market, it is for instance now expressly stated in the GDPR, recital 7, that natural persons should have control of their own personal data. It’s furthermore prescribed that legal and practical certainty for natural persons, economic operators and public authorities should be enhanced.
Data ownership, often discussed in legal doctrine, refers to both the possession of and responsibility for information. Ownership implies power as well as control. The control of information includes not just the ability to access, create, modify, package, derive benefit from, sell or remove data, but also the right to assign these access privileges to others. Many modern service providers give people access to their own data in machine readable format to download and use as they see fit. Proponents of increased data portability point to numerous, significant benefits for users, service providers, the broader public and society. For users, perhaps the most important benefits are the ability to choose between different service providers, create backups of their most important data (like photographs, tax returns, and financial information) while reducing the danger of becoming locked-into a single service provider, especially in a world where service providers may change business models or discontinue products. An example of how the principle of data portability has been implemented in practice is the Google takeout tool (https://takeout.google.com/settings/takeout/). With Google takeout consumers are able to download, export and move their data across the various google apps, e.g. Gmail, Calendar, Photos, Google+. The underlying purpose and principle behind the Google takeout tool is that the consumer, not Google, is the owner of their personal data. With Google takeout, and as per the principle of data portability, the consumers should have the choice to move their proprietary data from one provider to another.
To further strengthen the control over the user’s own data, the user should also be allowed to receive personal data concerning him/her which the user has provided to the data controller. Data controllers (such as ASPSPs) should furthermore under the GDPR be encouraged to develop interoperable formats that enable data portability, to apply whenever the data has been provided to the data controller based on user consent or the data processing is necessary for the performance of a contract between the parties. This is derived from recital 68 to the GDPR that reads: “(...) in a structured, commonly used, machine-readable and interoperable format, and to transmit it to another controller. Data controllers should be encouraged to develop interoperable formats that enable data portability.” Therefore, it is encouraged that ASPSPs should develop a dedicated interface, however it should not be the only way for PIS/AIS services to access the necessary data to offer their services. If it becomes mandatory for PIS/AIS to use the dedicated interface offered by the ASPSPs there is a risk that not all the personal data that the consumer wish to share is available via the dedicated interface. In the scenario of a mandatory dedicated interface, the personal data would hence be controlled by the ASPSP, and not the consumer. Provided that it is transparent, informed and voluntary for the consumer what data they are agree to share with third parties, e.g. PIS/AIS services, (e.g. user friendly and easy to understand) the users should have the right to dispose over their data as they wish. According to Art 20 in the GDPR the user shall have the right to receive the personal data concerning him/her, and also the right to have the personal data transmitted directly from one controller to another, where technically feasible.
Based on the importance today of user trust – for the online world and elsewhere - it is inevitably important that the user rights are respected and strengthened and that the user remains in full control. Users need to be empowered for this to happen. PIS/AIS services are today exactly empowering the user with the access to their own data, e.g. AIS services are providing the user with a level of insight on their own spending patterns that they have not previously been able to get from their own ASPSP. AIS services can also help the user aggregate their financial information which often time will be scattered across several ASPSP providers. As a user, to be able to stay in control of the data in the user’s own bank account, to be able to choose how to use that data and with what other online service, to be able to transfer that data to another service provider at a point in time and in a way that the user so chooses, is an important cornerstone of the user rights, also in line with the fundamental data privacy considerations not to be undermined by other regulations."