Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
From our point of view we assume that according to Art. 97 para. 5 of PSD2, we as a potential PISP and AISP will be able to rely on the authentication procedures provided by the ASPSP, incl. all RTS developed by EBA in that regard and as described in Chapter 1 and 2 of the draft RTS. In practice this means, that PISP/AISP will technically transfer all access requirements to the PSU - as they stand as if the PSU accessed his personal online banking web front-end - and that ASPSP have to reflect the SCA-requirements accordingly to their dedicated XS2A-interface.
Conversely, this means for example that we as an AISP/PISP do not have to implement the EXPLICIT mechanisms against fraudulent payment transactions outlined in Art. 1 para 3 (e) of EBA’s RTS-draft on top of the ASPSP’s procedures. However AISP/PISP have to implement their own security concepts based on the - as of today - more general requirements by Art. 5 para 5 (j) of PSD2 plus Art. 21 para. 5 and 6 of EBA’s RTS-draft.
For fostering PSU’s confidence in the security of the open banking market we recommend that the extent of reliance on ASPSP’s SCA procedures by AISP/PISP should be more detailed by the EBA-RTS with regard to security measures. Furthermore, on top security mechanisms by AISP/PISP could be implemented to further minimize phishing risks. Accordingly, we propose to amend Art. 21 para 5 and 6 of EBA’s RTS-draft with provisions on the extent of reliance on ASPSP’s procedures and explicit on top security mechanisms by AISP/PISP, such as:
- Own monitoring techniques to detect systematic phishing activities.
- Send clear and standardised return codes for warnings and errors to ASPSP (e.g. “PSU was not able to successfully complete SCA due to invalid PSCs”) to further minimize phishing risks. So an additional vice versa provision considering the already drafted Art. 22 para. 2 of EBA’s RTS-draft, which outlines an obligation for the ASPSP regarding notifications to the PISP/AISP.
(B) Handling of bulk-transactions, such as via EBICS:
As PSD2 and the provided RTS focus on - but are not limited to - private consumers acting as PSU (see e.g. Art. 4 para 10 of PSD2), market participants would highly benefit from a clarification by EBA, if the handling of bulk-transactions for legal persons via existing online communication standards, such as EBICS, is covered by the PSD2-scope. If not, e.g. a separate EBICs interface is to be further on provided by ASPSP. A clarification would help to start designing efficiently working API infrastructures to meet XS2A-needs for ASPSP.
Last but not least the increasing digitalisation of the payments market could enable additional security options, which e.g. allow authorities to pursue a centrally maintained EU-blacklist that automatically processes and provide information on conspicuous and obviously fraudulently acting payees on a real-time basis to which PSP could connect their IT infrastructures.
From our point of view as a potential PISP and AISP, we assume that the PSD2 definition of “sensitive payment data“, i.e. “data, including personalised security credentials which can be used to carry out fraud” is to be interpreted as follows:
- Considering EBA’s difficulties to substantiate in detail the provided definition of sensitive payment data and the rationale of Art. 4 (32) of PSD2 on the one hand as well as to overcome potential problems for the PSD2 market transposition on the other hand, hence in order to foster an EU-wide level playing field for the post-PSD2 market participants, we assume that the definition of “data, including personalised security credentials which can be used to carry out fraud” is limited to ONLINE PAYMENT FRAUD scenarios.
- Therefore our understanding as a PISP/AISP of “sensitive payment data” is a limitation to data that can be abused for FRAUDULENT ONLINE PAYMENTS.
To support our interpretation we would like to point out some of the major positive effects this understanding implies for the market.
- First of all ASPSP on an EU-wide level will be enabled to build PSD2/SCA-compliant interfaces, incl. PSU web front-ends with legally watertight limitations of data access and without complex and diverse layers to control appropriate access (e.g. considering Art. 8 para. 1 (a) of EBA’s RTS-draft in conjunction with Art. 67 para. 2 (e) of PSD2).
- ASPSP as well as PISP/AISP will be able to convey clear and straightforward rules and limitations with regard to payment account access, especially considering SCU and exemption-requirements on top.
- Despite the provision of Art. 66 para. 3 (e) of PSD2 the PISP will be enabled to store appropriate documentation on conducted authentication processes to meet the evidence requirements according to Art. 72 para. 1 to provide PSD2.
- A legally watertight data requesting process by AISP in an EU-level playing field with regard to Art. 67 para. 2 (e) of PSD2 as well as Art. 22 para. 1 (a) of EBA’s RTS draft, considering already established successful use cases for AIS (see in further detail below under (B) - Our understanding of Art. 67 para. 2 (e) of PSD2 in conjunction with Art. 8 para. 1 (a) of EBA’s RTS-draft).
We kindly encourage EBA to object if this does not reflect EBA’s view to enable market participants to build and maintain PSD2-compliant processes with an appropriate level of security of investment.
(B) Our understanding of Art. 67 para. 2 (e) of PSD2 in conjunction with Art. 8 para. 1 (a) of EBA’s RTS-draft:
From our point of view as a potential AISP, we assume that the PSD2 provision “the AISP shall (...) NOT REQUEST sensitive payment data linked to the payment accounts” is to be interpreted as follows:
- The AISP is according to Art. 97 para. 5 of PSD2 as well as to Art. 19 para. 2 of EBA’s RTS-draft able to rely on the authentication procedures provided by the ASPSP. That means the AISP is actually allowed to ask the PSU to key in - in the AISP’s front-end - his personalised security credentials to ACCESS the PSU’s payment account directly. This is due to the fact that the rationale of PSD2 implies that the PSU should not have to be redirected to an ASPSP front-end in order to use the AISP’s service, but that the authentication codes are forwarded by the AISP.
- As a consequence the provided wording in Art. 67 para. 2 (e) of PSD2 and in Art. 22 para. 1 (a) of EBA’s RTS simply determines that, when an AISP is REQUESTING the payment data of a PSU - AFTER the PSU authentication was successful and an ACCESS was established - the AISP shall not REQUEST (= technically call for) sensitive payment data (= personalised security credentials) in order to DISPLAY this data to the PSU.
- Considering our interpretation and Art. 8 para. 1 (a) of EBA’s RTS-draft, the ASPSP will have to provide PSU with a web front-end that does not disclose sensitive payment data (= personalised security credentials) as well as a direct access for AISP to this same content via a dedicated PSD2 XS2A-interface.
We kindly encourage EBA to object if this does not reflect EBA’s view to enable market participants to build and maintain PSD2-compliant processes with an appropriate level of security of investment.
From our point of view as a potential PISP and AISP, we assume that the currently provided exemptions contained in Chapter 2 for “online access” as well as “online credit transfer”, are - as they stand as part of the current draft - also applicable for the PSU’s access via an AISP and/or PISP. This assumption is based on Art. 97 para. 5 of PSD2, according to which PISPs/AISPs will be able to rely on the authentication procedures provided by the ASPSP, incl. all RTS developed by EBA in that regard and as described in Chapter 1 and 2 of the draft RTS. In practice this means, that PISP/AISP will technically transfer all access requirements to the PSU - as they stand as if he accessed his personal online banking web front-end - and that ASPSP have to reflect the SCA-requirements accordingly to their dedicated XS2A-interface. Again, we kindly encourage EBA to object if this does not reflect EBA’s view.
(B) PSU-will based approach for SCA-exemptions in favor of complex mandatory RTS:
It is understandable that as of today it is (still) difficult for EBA to develop a risk criteria based approach for SCA-exemptions that leads to an EU market-wide and audit resistant implementation of according exemptions. From our point of view there is a good chance that from a mid-term perspective there will be highly developed authentication solutions based on artificial intelligence (user voice or behaviour recognition tools) that might overcome these challenges. That is why from our perspective “behavioral data” could - as of today - be considered as an element for potential smart SCA-exemption solutions and not only as an on top tool for fraud prevention (see rationale no. 29 of the consultation paper).
Facing the current situation though, the proposed alternate solution by EBA contained in Art. 8 of EBA’s RTS-draft bears a risk of unnecessary complexity for everyone involved. Our major concern with the current draft of SCA-exemption is that all market participants will face major efforts to implement the complex requirements and moreover to explain the diverse requirements to their PSUs in a transparent and easily understandable way - e.g. starting with DIFFERENT EUR-values as exemptions for - according to PSD2 - cross-currency transfers.
That is why we would like to point out the possibility of an overall different, i.e. a PSU-will based approach, which could be comprised as follows:
- When being provided with new online access credentials (for new payment account or in the course of ASPSP’s PSD2 transposition), SCA in the sense of Art. 97 para 1 and 2 strictly applies without any exemption. This can be easily explained to PSUs by the need to balance the generally higher phishing and data protection risks in the open banking environment.
- In a second step the PSU decides upon personal SCA-exemptions for his PSP-account and at his own risk, i.e. on the basis of setting up his own update intervals for online account access (direct = indirect via any AISP), payee-whitelists as already proposed in Art. 8 para. 2 of EBA’s RTS-draft as well as individual amount limitations (for direct initiation = for indirect initiation via any PISP).
- The PSU options could be determined by EBA as hard criteria to be used by all EU ASPSP.
- To leave room for further technical developments the EBA-RTS could propose an optional criterion for PSU-will based exemptions on the basis of any artificial intelligence tools, if offered by ASPSP.
- The involved PSPs can - on the basis of contractual agreements - transparently outline to the PSU that PSPs cannot be held financially liable for fraudulent transactions, that were processed under application of the PSU-will based SCA-exemptions. For fraudulent transactions that were processed under strict application of SCA the general liability rules of PSD2 apply.
From our point of view a less detailed PSU-will based approach would lead to an overall less complex solution and in this way to divers benefits, such as:
- Less efforts for market participants to explain the requirements to their PSUs, as this would be feasible in a transparent and easily understandable way.
- Increased legal certainty and transparency as the PSPs would not be held financially responsible for highly seamless PSU-processes, as the PSU has to decide on his own risk what user convenience is worth to him.
- A more general PSU-will based SCA-exemption approach, incl. opportunities for further technical innovation, would be overall more sustainable.
We kindly encourage EBA to actively walktrough this alternative.
Moreover additional/specific requirements for AISP/PISP regarding the protection of PSC are outlined in Chapter 4 covering communication standards (see Art. 21 para. 5 and 6 of EBA’s RTS-draft).
We kindly encourage EBA to reconsider the general RTS’s structure in that regard as well as to consider a potential, rather general, i.e. risk-based demarcation provision that at least minimizes the interpretation scope or gives some direction on how to demarcate the different obligations.
With regard to EBA’s reasoning for Chapter 4 in general we initially refer to our input to Questions 1 and 4 on the extent of reliance on ASPSP’s SCA procedures and explicit on top security mechanisms by AISP/PISP as well as our understanding of the definition of “sensitive payment data” by Art. 4 (32) of PSD2. This input also has high relevance for the general understanding of future common and secure open standards of communication.
(B) Our understanding of the design of the ASPSP’s “communication interface”:
From our point of view as a potential PISP/AISP as well as an already active IT outsourcing service provider for ASPSP, who have to build and maintain a PSD2-compliant XS2A interface, we assume that the provision of offering “at least one communication interface” to serve the needs covered by Art. 19 para. 1 of EBA’s RTS-draft implies that EBA acknowledges the following facts:
- From a technical point of view one Application Programming Interface (API) could be designed to cover all requirements for common and secure open standards of communication for the purpose of identification, authentication, notification, and information, and the resultant provisions for the DIFFERENT participants concerned.
- Alternatively and if more practical for individual ASPSP more than one API could be developed to serve these needs.
We welcome this understanding as API-infrastructures provide highly developed technical solutions (e.g. process, rights and token management) for a strict sorting of differentiated processes, if just one interface, for example to cover AIS as well as PIS is designed. And the design of fewer APIs would imply more cost-efficient solutions for ASPSP as well as connecting market participants.
We also welcome that EBA did not further substantiate any technical provisions for the strict sorting of different PSP-communication ways within one interface as technical developments in that area are subject to constant improvements and should not be restricted to regulated alternatives.
We kindly encourage EBA to object if this does not reflect EBA’s view.
In addition, figo GmbH would highly recommend to add a mandatory language provision for any kind of literal communication between the addressees of Chapter 4. The mandatory use of English should at least apply for:
- the provided interface documentation by the ASPSP (see Art. 19 para 4 of PSD2),
- any literal error message shared between ASPSP and PISP/AISP,
- any literal warning message shared between ASPSP and PISP/AISP as well as
- any literal success message shared between ASPSP and PISP/AISP.
From our point of view an English minimum standard would already help market participants to benefit from the EU-pass opportunities provided by PSD2 in a more efficient way and to a larger extent. We kindly encourage EBA to consider an according RTS language provision.
Even more desirable - however presumably more challenging for EBA - would be an EU-wide mandatory and standardised list of error/warning/success messages with unambiguous codes and strictly applied purposes. German market participants like figo GmbH could provide EBA with more detailed input in that regard based on their experience with advantages and disadvantages in the course of the HBCI/FinTS standard messages developments over the last years.
figo GmbH generally agrees with the selected approach of the selected Option 1. However, as it is still unclear if any qualified trust service providers were to be designated under e-IDAS by October 2018, we see a strong need to foster a faster development in that area by EU-authorities. Workarounds or national stand-alone solutions will hardly lead to an EU-level playing field in the context of PSD2. We kindly ask EBA to provide market participants with information about any authorities and/or initiatives that could play a leading role in this regard and how market participants might be able to actively foster a fast progress of developments in that area.
(B) Our understanding of certificate’s attributes:
From our point of view as a potential PISP and AISP, we assume that the currently provided provision in Art. 20 para 3 (a) of EBA’s RTS-draft leads to obtaining and processing two certificates in our future PSD2-communication with ASPSP, i.e. a PISP as well as an AISP certificate (with regard to our business model we refer to a detailed description below). Due to different licensing/registration-arrangements, hence potential life cycle deviations as well as the necessary sorting of processes due to differing PSD2/RTS requirements for AIS and PIS this is an overall reasonable approach. We kindly encourage EBA to object if this does not reflect EBA’s view.
For the purpose of this consultation we focus our further description on the PSD2-scope. In that regard figo GmbH aims at becoming a BaFin-regulated Payment Institution, i.e. a licensed Payment Initiation Service Provider as well as a registered Account Information Service Provider in Germany. Our aspired post-PSD2 services in 2018 might be described on the basis of the following different contractual model options:
(1) figo acting as a licensed PISP by means of contractual relationships with
(a) non-PSD2-regulated companies, acting as payees (= charged B2B-service) as well as
(b) the payment service users (= free of charge user agreements with PIS-end users/payers)
and provided that sensitive payment data is not forwarded to non-PSD2-regulated third parties as well as that any data is not further utilised by figo but only for the provision of the payment initiation service.
(2) figo acting as an AISP subject to registration by means of a contractual relationship with
(a) non-PSD2-regulated data benefit providers (= charged B2B-service), who only make use of the AIS-data for a user-friendly feature of their actual product range, such as account change/alert/monitoring providers, comparison portals or credit portals (in the latter case for risk management/credit rating purposes) as well as
(b) the payment service users (= free of charge user agreements with AIS-end users)
and provided that sensitive payment data is not forwarded to non-PSD2-regulated third parties as well as that other data is only forwarded on the basis of an explicit consent by the AIS-end user with forwarding certain earmarked AIS-data to a specific data benefit provider in compliance with relevant data protection rules.
(3) figo acting as a PSD2 services outsourcing partner for licensed or subject to registration PISP or AISP (e.g. ASPSP providing PIS/AIS services to their customers or AISP/PISP who do not want to build the overall IT infrastructure needed to provide their licensed/registered services) and without any contractual relationship with the end-user.
(4) figo acting as a XS2A Service Provider, i.e. an IT outsourcing service provider for ASPSP, who have to build and maintain a PSD2-compliant XS2A interface.
We are aware that option (2) was not considered when the PSD2 content was finalised. As a consequence, a few strict interpretations of PSD2 details have been expressed lately, that e.g. the directive would not allow to hold a PIS-license as well as an AIS-registration by a single company or that Art. 67 para. 2 (f) of PSD2 would imply a similar strict interdiction of further data utilisation by AISP as Art. 66 para. 3 (g) of PSD2 does for PIS.
Today’s advanced market developments however show an urgent need for the proposed overall concept by figo GmbH. Established innovations and successful use cases would be hindered to a large extent, if the described option (2) will not be implemented in a legally watertight way. From our point of view, especially context-related use cases of AIS are a major driver of the PSD2-intended innovation. AIS-end users tend to share their personal data in cases of benefits, such as more convenient and automated user processes for example. And there is still considerable room for more innovative business concepts on that PSD2-basis, which will lead to further economic growth for the European market, if it is not unnecessarily over-regulated. The law and regulatory requirements have to involve itself on a second level, i.e. to meet these newly developed market needs and make sure that the processes requested by the consumer are built and maintained in a secure way, instead of generally limiting the consumer’s freedom. A potentially strict interdiction of further data utilisation by AISP would only have an unfortunate inhibitory effect on the actually intended innovation by PSD2. In the medium term, consumer freedom will assert itself eventually (see recent antitrust authorities’ decisions in favor of this development in Europe).
Assuming accordingly that data benefit providers will be allowed to bring their AIS-featured products to the market, another PSD2 loophole has to be rectified. Given their business model and strategies, the majority of data benefit providers, who only make use of AIS as a small component of their product range do not aim at becoming a registered AISP or being “treated as a payment institution”. That is why today they already make use of market participants like figo GmbH to access the financial resources of their B2C-clients. Looking ahead and based on our extensive business partner experience, data benefit providers want a full PSD2-compliant service support by a regulated AISP next to the option of outsourcing the IT infrastructure needs for AIS-components. They would rather forgo successful consumer friendly features instead of applying for an own AISP-registration. This is due to the fact that from a market perspective the latter overall requires similarly high standards and efforts as becoming a fully licensed payment institution.
Moreover, from our point of view, bundling AISP provide a win-win for all market participants, as implementing contractual model option (2) in a legally watertight way would lead to increased consumer and data protection as well as IT-Security by
- upstream (and we propose regulatory binding) “know your third party”-processes, incl. a risk-based and scaled transfer of PSD2 requirements to data benefit providers,
- streamlined (but clearly and technically sorted from PIS processes) and transparent communication processes between ASPSP and AISP,
- implementing centrally enforceable and effectively controllable standards by EU-wide and national supervisory bodies as well as
- the establishment of high-quality API infrastructure standards.
That is why, we hereby make use of the possibility to initially state that an explicit registration exception for data benefit providers is needed on the condition that these market participants engage registered AISP. At best a fully EU-harmonised clarification can be achieved, e.g. being provided as part of EBA’s mandate concerning the information to be provided to the competent authorities in the application for the authorisation of payment institutions covered by Art. 5 para. 5 of PSD2.
With regard to our services beyond PSD2 coverage we would like to share our view with EBA on how they could have an active role in further fostering innovation and growth developments in the open banking market. In a first step, a severe consideration by EBA of all provided consultation input with regard to a need for clarification on the PSD2-scope helps the market to establish a legally watertight basis, what will consequently foster innovations. ASPSP can more clearly define, which sort of access they can legally monetise, e.g. by offering charged and hence so-called “premium API access” to third parties and on the basis of explicit consent of end-users.
Moreover, we kindly encourage EBA to clarify in their rationales of the provided RTS-draft, that PSD2 does not prevent market participants to make bilateral agreements and obtain explicit customer consent on premium access to banking data beyond the PSD2/RTS-limitations. For example the growing market for XS2B(rokerage) could be actively supported by a clear statement from EBA officials. Given this, the urgently needed and slowly growing cooperation between banking incumbents and FinTechs would be actively supported by an EU authority which will lead to general economic growth for all EU market participants. As a positive side effect a clear statement in that regard would override the general veto players, who still discuss principles of the PSD2-scope that are no longer questionable after PSD2 entered into force on 12 January, 2016. If this view is not shared by EBA as well as other involved authorities and moreover by banking incumbents, we expect a much slower and demanding process but eventually still the same result in this matter. As from a consumer perspective as well as from a competition law perspective, there is no reasonable ground for a legal discrimination of non-payment accounts.
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?
(A) Extent of reliance on ASPSP’s SCA procedures and on top security mechanisms by AISP/PISP:From our point of view we assume that according to Art. 97 para. 5 of PSD2, we as a potential PISP and AISP will be able to rely on the authentication procedures provided by the ASPSP, incl. all RTS developed by EBA in that regard and as described in Chapter 1 and 2 of the draft RTS. In practice this means, that PISP/AISP will technically transfer all access requirements to the PSU - as they stand as if the PSU accessed his personal online banking web front-end - and that ASPSP have to reflect the SCA-requirements accordingly to their dedicated XS2A-interface.
Conversely, this means for example that we as an AISP/PISP do not have to implement the EXPLICIT mechanisms against fraudulent payment transactions outlined in Art. 1 para 3 (e) of EBA’s RTS-draft on top of the ASPSP’s procedures. However AISP/PISP have to implement their own security concepts based on the - as of today - more general requirements by Art. 5 para 5 (j) of PSD2 plus Art. 21 para. 5 and 6 of EBA’s RTS-draft.
For fostering PSU’s confidence in the security of the open banking market we recommend that the extent of reliance on ASPSP’s SCA procedures by AISP/PISP should be more detailed by the EBA-RTS with regard to security measures. Furthermore, on top security mechanisms by AISP/PISP could be implemented to further minimize phishing risks. Accordingly, we propose to amend Art. 21 para 5 and 6 of EBA’s RTS-draft with provisions on the extent of reliance on ASPSP’s procedures and explicit on top security mechanisms by AISP/PISP, such as:
- Own monitoring techniques to detect systematic phishing activities.
- Send clear and standardised return codes for warnings and errors to ASPSP (e.g. “PSU was not able to successfully complete SCA due to invalid PSCs”) to further minimize phishing risks. So an additional vice versa provision considering the already drafted Art. 22 para. 2 of EBA’s RTS-draft, which outlines an obligation for the ASPSP regarding notifications to the PISP/AISP.
(B) Handling of bulk-transactions, such as via EBICS:
As PSD2 and the provided RTS focus on - but are not limited to - private consumers acting as PSU (see e.g. Art. 4 para 10 of PSD2), market participants would highly benefit from a clarification by EBA, if the handling of bulk-transactions for legal persons via existing online communication standards, such as EBICS, is covered by the PSD2-scope. If not, e.g. a separate EBICs interface is to be further on provided by ASPSP. A clarification would help to start designing efficiently working API infrastructures to meet XS2A-needs for ASPSP.
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.
figo agrees with EBA’s reasoning and draft RTS in that regard.Question 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?
No, figo explicitly supports EBA’s clear rationale that one mobile device must be enabled in a secure manner to provide a sufficient SCA-solution. Any over-regulation should be currently avoided to not prevent technological and market developments to overcome one of the major challenges of the PSD2, i.e. to find PSD2/RTS-compliant but still seamless ways to handle SCA. figo would actively support any initiatives on an EU-level to discuss smart solution approaches for this challenge with other market participants. From our point of view as a potential PISP and AISP, we assume that there still might be some potential for conflicts, as PISP/AISP might have more or less efforts with technically transferring SCA-techniques in line with given reliance on ASPSP’s SCA procedures, dependent on the different solutions developed by ASPSP. A joint discussion and cooperation in that matter - initiated and/or fostered by EU-authorities - could prevent market participants from investing in divers and/or PSU-unfriendly stand-alone solutions, which do not prevail in the long-term. Moreover, when developing an appropriate authentication elements’ risk-resistance, all 2nd level risk mitigation mechanisms should be considered, which are to be implemented on top (see our input on Question 1).Last but not least the increasing digitalisation of the payments market could enable additional security options, which e.g. allow authorities to pursue a centrally maintained EU-blacklist that automatically processes and provide information on conspicuous and obviously fraudulently acting payees on a real-time basis to which PSP could connect their IT infrastructures.
Question 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?
(A) Our understanding of the definition of “sensitive payment data” by Art. 4 (32) of PSD2:From our point of view as a potential PISP and AISP, we assume that the PSD2 definition of “sensitive payment data“, i.e. “data, including personalised security credentials which can be used to carry out fraud” is to be interpreted as follows:
- Considering EBA’s difficulties to substantiate in detail the provided definition of sensitive payment data and the rationale of Art. 4 (32) of PSD2 on the one hand as well as to overcome potential problems for the PSD2 market transposition on the other hand, hence in order to foster an EU-wide level playing field for the post-PSD2 market participants, we assume that the definition of “data, including personalised security credentials which can be used to carry out fraud” is limited to ONLINE PAYMENT FRAUD scenarios.
- Therefore our understanding as a PISP/AISP of “sensitive payment data” is a limitation to data that can be abused for FRAUDULENT ONLINE PAYMENTS.
To support our interpretation we would like to point out some of the major positive effects this understanding implies for the market.
- First of all ASPSP on an EU-wide level will be enabled to build PSD2/SCA-compliant interfaces, incl. PSU web front-ends with legally watertight limitations of data access and without complex and diverse layers to control appropriate access (e.g. considering Art. 8 para. 1 (a) of EBA’s RTS-draft in conjunction with Art. 67 para. 2 (e) of PSD2).
- ASPSP as well as PISP/AISP will be able to convey clear and straightforward rules and limitations with regard to payment account access, especially considering SCU and exemption-requirements on top.
- Despite the provision of Art. 66 para. 3 (e) of PSD2 the PISP will be enabled to store appropriate documentation on conducted authentication processes to meet the evidence requirements according to Art. 72 para. 1 to provide PSD2.
- A legally watertight data requesting process by AISP in an EU-level playing field with regard to Art. 67 para. 2 (e) of PSD2 as well as Art. 22 para. 1 (a) of EBA’s RTS draft, considering already established successful use cases for AIS (see in further detail below under (B) - Our understanding of Art. 67 para. 2 (e) of PSD2 in conjunction with Art. 8 para. 1 (a) of EBA’s RTS-draft).
We kindly encourage EBA to object if this does not reflect EBA’s view to enable market participants to build and maintain PSD2-compliant processes with an appropriate level of security of investment.
(B) Our understanding of Art. 67 para. 2 (e) of PSD2 in conjunction with Art. 8 para. 1 (a) of EBA’s RTS-draft:
From our point of view as a potential AISP, we assume that the PSD2 provision “the AISP shall (...) NOT REQUEST sensitive payment data linked to the payment accounts” is to be interpreted as follows:
- The AISP is according to Art. 97 para. 5 of PSD2 as well as to Art. 19 para. 2 of EBA’s RTS-draft able to rely on the authentication procedures provided by the ASPSP. That means the AISP is actually allowed to ask the PSU to key in - in the AISP’s front-end - his personalised security credentials to ACCESS the PSU’s payment account directly. This is due to the fact that the rationale of PSD2 implies that the PSU should not have to be redirected to an ASPSP front-end in order to use the AISP’s service, but that the authentication codes are forwarded by the AISP.
- As a consequence the provided wording in Art. 67 para. 2 (e) of PSD2 and in Art. 22 para. 1 (a) of EBA’s RTS simply determines that, when an AISP is REQUESTING the payment data of a PSU - AFTER the PSU authentication was successful and an ACCESS was established - the AISP shall not REQUEST (= technically call for) sensitive payment data (= personalised security credentials) in order to DISPLAY this data to the PSU.
- Considering our interpretation and Art. 8 para. 1 (a) of EBA’s RTS-draft, the ASPSP will have to provide PSU with a web front-end that does not disclose sensitive payment data (= personalised security credentials) as well as a direct access for AISP to this same content via a dedicated PSD2 XS2A-interface.
We kindly encourage EBA to object if this does not reflect EBA’s view to enable market participants to build and maintain PSD2-compliant processes with an appropriate level of security of investment.
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?
(A) Our understanding of the terms “online access”/“online credit transfer” contained in Chapter 2:From our point of view as a potential PISP and AISP, we assume that the currently provided exemptions contained in Chapter 2 for “online access” as well as “online credit transfer”, are - as they stand as part of the current draft - also applicable for the PSU’s access via an AISP and/or PISP. This assumption is based on Art. 97 para. 5 of PSD2, according to which PISPs/AISPs will be able to rely on the authentication procedures provided by the ASPSP, incl. all RTS developed by EBA in that regard and as described in Chapter 1 and 2 of the draft RTS. In practice this means, that PISP/AISP will technically transfer all access requirements to the PSU - as they stand as if he accessed his personal online banking web front-end - and that ASPSP have to reflect the SCA-requirements accordingly to their dedicated XS2A-interface. Again, we kindly encourage EBA to object if this does not reflect EBA’s view.
(B) PSU-will based approach for SCA-exemptions in favor of complex mandatory RTS:
It is understandable that as of today it is (still) difficult for EBA to develop a risk criteria based approach for SCA-exemptions that leads to an EU market-wide and audit resistant implementation of according exemptions. From our point of view there is a good chance that from a mid-term perspective there will be highly developed authentication solutions based on artificial intelligence (user voice or behaviour recognition tools) that might overcome these challenges. That is why from our perspective “behavioral data” could - as of today - be considered as an element for potential smart SCA-exemption solutions and not only as an on top tool for fraud prevention (see rationale no. 29 of the consultation paper).
Facing the current situation though, the proposed alternate solution by EBA contained in Art. 8 of EBA’s RTS-draft bears a risk of unnecessary complexity for everyone involved. Our major concern with the current draft of SCA-exemption is that all market participants will face major efforts to implement the complex requirements and moreover to explain the diverse requirements to their PSUs in a transparent and easily understandable way - e.g. starting with DIFFERENT EUR-values as exemptions for - according to PSD2 - cross-currency transfers.
That is why we would like to point out the possibility of an overall different, i.e. a PSU-will based approach, which could be comprised as follows:
- When being provided with new online access credentials (for new payment account or in the course of ASPSP’s PSD2 transposition), SCA in the sense of Art. 97 para 1 and 2 strictly applies without any exemption. This can be easily explained to PSUs by the need to balance the generally higher phishing and data protection risks in the open banking environment.
- In a second step the PSU decides upon personal SCA-exemptions for his PSP-account and at his own risk, i.e. on the basis of setting up his own update intervals for online account access (direct = indirect via any AISP), payee-whitelists as already proposed in Art. 8 para. 2 of EBA’s RTS-draft as well as individual amount limitations (for direct initiation = for indirect initiation via any PISP).
- The PSU options could be determined by EBA as hard criteria to be used by all EU ASPSP.
- To leave room for further technical developments the EBA-RTS could propose an optional criterion for PSU-will based exemptions on the basis of any artificial intelligence tools, if offered by ASPSP.
- The involved PSPs can - on the basis of contractual agreements - transparently outline to the PSU that PSPs cannot be held financially liable for fraudulent transactions, that were processed under application of the PSU-will based SCA-exemptions. For fraudulent transactions that were processed under strict application of SCA the general liability rules of PSD2 apply.
From our point of view a less detailed PSU-will based approach would lead to an overall less complex solution and in this way to divers benefits, such as:
- Less efforts for market participants to explain the requirements to their PSUs, as this would be feasible in a transparent and easily understandable way.
- Increased legal certainty and transparency as the PSPs would not be held financially responsible for highly seamless PSU-processes, as the PSU has to decide on his own risk what user convenience is worth to him.
- A more general PSU-will based SCA-exemption approach, incl. opportunities for further technical innovation, would be overall more sustainable.
We kindly encourage EBA to actively walktrough this alternative.
Question 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?
From our point of view we understand that these RTS Chapter applies to the general protection of PSCs issued by ASPSP and handled by different market participants as well as any PSC that PISP/AISP issue for PSU in addition and generally agree with EBA’s reasoning on their protection. However, we would like you to consider that the current structure of the draft RTS might be partly misleading. The demarcation between the extent of reliance on ASPSP’s PSC protection and authentication procedures and any on top security mechanisms for these original PSC by AISP/PISP as well as applicable mechanisms for PSCs issued by AISP/PISP could be more clearly laid out by the RTS. The current status and wording of Chapter 3 implies that AISP/PISP have to interpret for themselves which obligations are applicable for them and vice versa, e.g. with regard to Art. 12 of EBA’s RTS-draft outlining requirements for the association of the payer with personalised security credentials, authentication devices and software.Moreover additional/specific requirements for AISP/PISP regarding the protection of PSC are outlined in Chapter 4 covering communication standards (see Art. 21 para. 5 and 6 of EBA’s RTS-draft).
We kindly encourage EBA to reconsider the general RTS’s structure in that regard as well as to consider a potential, rather general, i.e. risk-based demarcation provision that at least minimizes the interpretation scope or gives some direction on how to demarcate the different obligations.
Question 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?
(A) Extent of reliance on ASPSP’s SCA procedures and on top security mechanisms by AISP/PISP as well as our understanding of the definition of “sensitive payment data” by Art. 4 (32) of PSD2:With regard to EBA’s reasoning for Chapter 4 in general we initially refer to our input to Questions 1 and 4 on the extent of reliance on ASPSP’s SCA procedures and explicit on top security mechanisms by AISP/PISP as well as our understanding of the definition of “sensitive payment data” by Art. 4 (32) of PSD2. This input also has high relevance for the general understanding of future common and secure open standards of communication.
(B) Our understanding of the design of the ASPSP’s “communication interface”:
From our point of view as a potential PISP/AISP as well as an already active IT outsourcing service provider for ASPSP, who have to build and maintain a PSD2-compliant XS2A interface, we assume that the provision of offering “at least one communication interface” to serve the needs covered by Art. 19 para. 1 of EBA’s RTS-draft implies that EBA acknowledges the following facts:
- From a technical point of view one Application Programming Interface (API) could be designed to cover all requirements for common and secure open standards of communication for the purpose of identification, authentication, notification, and information, and the resultant provisions for the DIFFERENT participants concerned.
- Alternatively and if more practical for individual ASPSP more than one API could be developed to serve these needs.
We welcome this understanding as API-infrastructures provide highly developed technical solutions (e.g. process, rights and token management) for a strict sorting of differentiated processes, if just one interface, for example to cover AIS as well as PIS is designed. And the design of fewer APIs would imply more cost-efficient solutions for ASPSP as well as connecting market participants.
We also welcome that EBA did not further substantiate any technical provisions for the strict sorting of different PSP-communication ways within one interface as technical developments in that area are subject to constant improvements and should not be restricted to regulated alternatives.
We kindly encourage EBA to object if this does not reflect EBA’s view.
Question 8: In particular, do you agree that the use of ISO 20022 elements, components or approved message definitions, if available, should be required to ensure the interoperability of different technological communication solutions implemented between PSPs for the provision of AIS, PIS or for the confirmation on the availability of funds? Do you see any particular technical constraint that would prevent the use of such industry standards?
figo GmbH explicitly supports any reference to international industry standards when appropriate instead of reinventing independant standardised requirements for the post PSD2-world.In addition, figo GmbH would highly recommend to add a mandatory language provision for any kind of literal communication between the addressees of Chapter 4. The mandatory use of English should at least apply for:
- the provided interface documentation by the ASPSP (see Art. 19 para 4 of PSD2),
- any literal error message shared between ASPSP and PISP/AISP,
- any literal warning message shared between ASPSP and PISP/AISP as well as
- any literal success message shared between ASPSP and PISP/AISP.
From our point of view an English minimum standard would already help market participants to benefit from the EU-pass opportunities provided by PSD2 in a more efficient way and to a larger extent. We kindly encourage EBA to consider an according RTS language provision.
Even more desirable - however presumably more challenging for EBA - would be an EU-wide mandatory and standardised list of error/warning/success messages with unambiguous codes and strictly applied purposes. German market participants like figo GmbH could provide EBA with more detailed input in that regard based on their experience with advantages and disadvantages in the course of the HBCI/FinTS standard messages developments over the last years.
Question 9: With regards to identification between PSPs, do you agree that website certificates issued by a qualified trust service provider under an e-IDAS policy would be suitable and allow for the use of all common types of devices (such as computers, tablets and mobile phones) for carrying out different payment services ?
(A) Qualified trusted service providers:figo GmbH generally agrees with the selected approach of the selected Option 1. However, as it is still unclear if any qualified trust service providers were to be designated under e-IDAS by October 2018, we see a strong need to foster a faster development in that area by EU-authorities. Workarounds or national stand-alone solutions will hardly lead to an EU-level playing field in the context of PSD2. We kindly ask EBA to provide market participants with information about any authorities and/or initiatives that could play a leading role in this regard and how market participants might be able to actively foster a fast progress of developments in that area.
(B) Our understanding of certificate’s attributes:
From our point of view as a potential PISP and AISP, we assume that the currently provided provision in Art. 20 para 3 (a) of EBA’s RTS-draft leads to obtaining and processing two certificates in our future PSD2-communication with ASPSP, i.e. a PISP as well as an AISP certificate (with regard to our business model we refer to a detailed description below). Due to different licensing/registration-arrangements, hence potential life cycle deviations as well as the necessary sorting of processes due to differing PSD2/RTS requirements for AIS and PIS this is an overall reasonable approach. We kindly encourage EBA to object if this does not reflect EBA’s view.
Question 10: With regards to the frequency with which AIS providers can request information from designated payment accounts when the payment service user is not actively requesting such information, do you agree that the proposed limit of no more than two times a day achieve an appropriate balance between allowing AISP to provide updated information to their users while not negatively impacting the availability of the ASPSP’s communication interface? If not, please indicate what would be in your view the appropriate frequency and rationale for such frequency.
From our point of view as a potential AISP, EBA should actively incentify a way more efficient updating procedure, i.e. an alternative option (c) to Art. 22 para. 5 (b), offering the option for ASPSP to provide push services via their XS2A interfaces connected to actual account balance changes. In practise this means the ASPSP provide AISP who identified themselves in an to be determined way as “permanent connectors” with active push services, in case balances of connected accounts change. In this way it is most likely that the minimum amount of transmitted data volume would be generated. ASPSP as well as AISP would benefit from this way more efficient procedure.Please select which category best describes you and/or your organisation
[Other "]"If you selected "Other", please provide details
We describe figo GmbH as a “Banking Service Provider”. We offer B2B-services relating to the third party payment account access covered by PSD2 as well as services beyond that coverage. Considering PSD2, we aim at becoming a BaFin-regulated Payment Institution, i.e. Payment Initiation Service Provider as well as Account Information Service Provider in Germany after the national implementation of PSD2. We provided a detailed description of our PSD2-related business model as part of the following services description.Please select which category best describes the services provided by you/your organisation
[Other"]"If you selected "Other", please provide details
We describe figo GmbH as a “Banking Service Provider”. We offer B2B-services relating to the third party payment account access covered by PSD2 as well as services beyond that coverage.For the purpose of this consultation we focus our further description on the PSD2-scope. In that regard figo GmbH aims at becoming a BaFin-regulated Payment Institution, i.e. a licensed Payment Initiation Service Provider as well as a registered Account Information Service Provider in Germany. Our aspired post-PSD2 services in 2018 might be described on the basis of the following different contractual model options:
(1) figo acting as a licensed PISP by means of contractual relationships with
(a) non-PSD2-regulated companies, acting as payees (= charged B2B-service) as well as
(b) the payment service users (= free of charge user agreements with PIS-end users/payers)
and provided that sensitive payment data is not forwarded to non-PSD2-regulated third parties as well as that any data is not further utilised by figo but only for the provision of the payment initiation service.
(2) figo acting as an AISP subject to registration by means of a contractual relationship with
(a) non-PSD2-regulated data benefit providers (= charged B2B-service), who only make use of the AIS-data for a user-friendly feature of their actual product range, such as account change/alert/monitoring providers, comparison portals or credit portals (in the latter case for risk management/credit rating purposes) as well as
(b) the payment service users (= free of charge user agreements with AIS-end users)
and provided that sensitive payment data is not forwarded to non-PSD2-regulated third parties as well as that other data is only forwarded on the basis of an explicit consent by the AIS-end user with forwarding certain earmarked AIS-data to a specific data benefit provider in compliance with relevant data protection rules.
(3) figo acting as a PSD2 services outsourcing partner for licensed or subject to registration PISP or AISP (e.g. ASPSP providing PIS/AIS services to their customers or AISP/PISP who do not want to build the overall IT infrastructure needed to provide their licensed/registered services) and without any contractual relationship with the end-user.
(4) figo acting as a XS2A Service Provider, i.e. an IT outsourcing service provider for ASPSP, who have to build and maintain a PSD2-compliant XS2A interface.
We are aware that option (2) was not considered when the PSD2 content was finalised. As a consequence, a few strict interpretations of PSD2 details have been expressed lately, that e.g. the directive would not allow to hold a PIS-license as well as an AIS-registration by a single company or that Art. 67 para. 2 (f) of PSD2 would imply a similar strict interdiction of further data utilisation by AISP as Art. 66 para. 3 (g) of PSD2 does for PIS.
Today’s advanced market developments however show an urgent need for the proposed overall concept by figo GmbH. Established innovations and successful use cases would be hindered to a large extent, if the described option (2) will not be implemented in a legally watertight way. From our point of view, especially context-related use cases of AIS are a major driver of the PSD2-intended innovation. AIS-end users tend to share their personal data in cases of benefits, such as more convenient and automated user processes for example. And there is still considerable room for more innovative business concepts on that PSD2-basis, which will lead to further economic growth for the European market, if it is not unnecessarily over-regulated. The law and regulatory requirements have to involve itself on a second level, i.e. to meet these newly developed market needs and make sure that the processes requested by the consumer are built and maintained in a secure way, instead of generally limiting the consumer’s freedom. A potentially strict interdiction of further data utilisation by AISP would only have an unfortunate inhibitory effect on the actually intended innovation by PSD2. In the medium term, consumer freedom will assert itself eventually (see recent antitrust authorities’ decisions in favor of this development in Europe).
Assuming accordingly that data benefit providers will be allowed to bring their AIS-featured products to the market, another PSD2 loophole has to be rectified. Given their business model and strategies, the majority of data benefit providers, who only make use of AIS as a small component of their product range do not aim at becoming a registered AISP or being “treated as a payment institution”. That is why today they already make use of market participants like figo GmbH to access the financial resources of their B2C-clients. Looking ahead and based on our extensive business partner experience, data benefit providers want a full PSD2-compliant service support by a regulated AISP next to the option of outsourcing the IT infrastructure needs for AIS-components. They would rather forgo successful consumer friendly features instead of applying for an own AISP-registration. This is due to the fact that from a market perspective the latter overall requires similarly high standards and efforts as becoming a fully licensed payment institution.
Moreover, from our point of view, bundling AISP provide a win-win for all market participants, as implementing contractual model option (2) in a legally watertight way would lead to increased consumer and data protection as well as IT-Security by
- upstream (and we propose regulatory binding) “know your third party”-processes, incl. a risk-based and scaled transfer of PSD2 requirements to data benefit providers,
- streamlined (but clearly and technically sorted from PIS processes) and transparent communication processes between ASPSP and AISP,
- implementing centrally enforceable and effectively controllable standards by EU-wide and national supervisory bodies as well as
- the establishment of high-quality API infrastructure standards.
That is why, we hereby make use of the possibility to initially state that an explicit registration exception for data benefit providers is needed on the condition that these market participants engage registered AISP. At best a fully EU-harmonised clarification can be achieved, e.g. being provided as part of EBA’s mandate concerning the information to be provided to the competent authorities in the application for the authorisation of payment institutions covered by Art. 5 para. 5 of PSD2.
With regard to our services beyond PSD2 coverage we would like to share our view with EBA on how they could have an active role in further fostering innovation and growth developments in the open banking market. In a first step, a severe consideration by EBA of all provided consultation input with regard to a need for clarification on the PSD2-scope helps the market to establish a legally watertight basis, what will consequently foster innovations. ASPSP can more clearly define, which sort of access they can legally monetise, e.g. by offering charged and hence so-called “premium API access” to third parties and on the basis of explicit consent of end-users.
Moreover, we kindly encourage EBA to clarify in their rationales of the provided RTS-draft, that PSD2 does not prevent market participants to make bilateral agreements and obtain explicit customer consent on premium access to banking data beyond the PSD2/RTS-limitations. For example the growing market for XS2B(rokerage) could be actively supported by a clear statement from EBA officials. Given this, the urgently needed and slowly growing cooperation between banking incumbents and FinTechs would be actively supported by an EU authority which will lead to general economic growth for all EU market participants. As a positive side effect a clear statement in that regard would override the general veto players, who still discuss principles of the PSD2-scope that are no longer questionable after PSD2 entered into force on 12 January, 2016. If this view is not shared by EBA as well as other involved authorities and moreover by banking incumbents, we expect a much slower and demanding process but eventually still the same result in this matter. As from a consumer perspective as well as from a competition law perspective, there is no reasonable ground for a legal discrimination of non-payment accounts.