Response to consultation on the Guidelines on the conditions to be met to benefit from an exemption from contingency measures under Article 33(6) of Regulation (EU) 2018/389 (RTS on SCA & CSC)

Go back

Question 1: Do you agree with the EBA’s assessments on KPIs and the calculation of uptime and downtime and the ASPSP submission of a plan to publishing statistics, the options that EBA considered and progressed or discarded, and the requirements proposed in Guideline 2 and 3? If not, please provide detail on other KPIs or calculation methods that you consider more suitable and your reasoning for doing so.

Our answer here builds on our first FDATA Proposed Exemption Criteria, that “the PSD2 dedicated interface is widely available”, with the key point being:

● The uptime of the PSD2 dedicated interface is greater than or equal to both the ASPSP’s private dedicated interface and the ASPSP’s PSU interface.

FDATA agree with the calculation of uptime and downtime in relation to guidelines 2.1, 2.2 and 2.4, and stress the importance of such a metric when there is a fully functional PSD2 ecosystem. It is to state the obvious that a PSD2 dedicated interface needs to be available in order to succeed.

The definitions defined in guidelines 2.1, 2.2 and 2.4 are transparent and the private interfaces provide CAs with a clear benchmark the dedicated interfaces must meet or better in order to pass FDATA Proposed Exemption Criteria 1 and ultimately receive an exemption.

Whilst agreeing with the metrics, FDATA have some feelings of trepidation around self-attestation of ASPSP conformance. Our recommendation is that CAs make use of simple conformance tools to regularly test the interface’s availability. FDATA elaborate on the detail around the conformance tools in response to question 5.

Although FDATA support the EBA’s calculation of availability, our membership wishes to highlight that due consideration has not been given to degraded services. Despite the fact that a system may be ‘available’, this does not mean that it is delivering services in a way that satisfies its use. FDATA’s extensive experience in the PSD2 ecosystem means we would like to stress the importance of the EBA elaborating on this point, and would highly recommend the use of FDATA Proposed Exemption Criteria 2-7 to address the possibility of degraded services.

Question 2: Do you agree with the EBA’s assessments on stress testing and the options it considered and progressed or discarded, and the requirements proposed in Guideline 4? If not, please provide your reasoning.

Our answer here builds on our second recommended exemption criterion, that “the PSD2 dedicated interface is adequately responsive and maintains performance at scale” the key points here being:

● The response time of the PSD2 dedicated interface is quicker than or equal to the performance of both an ASPSP’s private dedicated interface and the ASPSPs PSU interface, at similar levels of stress.

FDATA share the view of the EBA in article 32 (2), that for PSD2 dedicated interfaces to be widely adopted they need to be responsive.

FDATA agree with the indicators in guideline 2.3 and stress the importance of such a metric. The indicators defined in the guidelines are transparent and provide a clear indication of performance. An ASPSP’s private interfaces that back an ASPSP’s PSU interface provide CAs with a clear level to which an ASPSP’s PSD2 dedicated interface must be match or better in order to satisfy this part of the exemption criterion. For the avoidance of doubt, FDATA believe that a PSD2 dedicated interface that is slower than an ASPSP PSU interface backed by an ASPSP’s private dedicated interface is completely unacceptable. We would again stress to the EBA that these two interactions are in fact directly comparable and would encourage the EBA to revise paragraph 24 of the consultation paper that states that they are not.

Although FDATA foresee it being hard for ASPSPs to measure stress of the dedicated interface against the private interface, from experiences around the EU to date, the response times of the PSD2 dedicated interface will either be similar or vastly different to the private interface. Consequently, we believe that CAs are able to assess the responsiveness of a PSD2 dedicated interface with confidence.

● The dedicated interface can endure similar levels of stress as the private interface can.

This criteria must assure TPPs that the PSD2 dedicated interface will allow long-term business continuity and scalability.

FDATA refer to the EBA’s comments on stress testing as a sensible way to measure the following criteria. FDATA agree with the examples provided in guideline 4.2 and foresee these examples providing scenarios that match real-world use cases.

When FDATA members discussed measurable ways to test how the dedicated interfaces handle stress, the recommendation was that CAs interact with ASPSPs private dedicated interfaces and create minimum stress level(s). These minimum stress level(s) should fulfil the following criteria:

1. The minimum stress level(s) are handled by the private interface.
2. If the PSD2 dedicated interface is able to endure minimum stress levels, then the dedicated interface can be reasonably assessed to maintain this endurance with scale.

The minimum stress levels provide a means for CAs to determine whether a PSD2 dedicated interface is capable of withstanding minimum stress levels, in order to deem whether they are eligible for exemption.

● If the dedicated interface is unable to process TPP requests due to stress, consistent and conformant errors are provided to TPPs.

Lastly, if the dedicated interface is unable to process TPP requests due to stress, consistent and conformant errors are provided to TPPs. This would give TPP’s consistent warning when an PSD2 dedicated interface was under severe stress and allowing TPPs to react accordingly. CAs should be expected to test that the PSD2 dedicated interfaces are able to consistently manage such situations.

Question 3: Do you agree with the EBA’s assessments on monitoring? If not, please provide your reasoning.

Our answer here builds on our seventh recommended exemption criterion, that “the PSD2 dedicated interface is appropriately monitored providing confidence in stability”, with the key point being that:

● An ASPSP can provide evidence that their PSD2 dedicated interface has passed [each FDATA Proposed Exemption Criteria 1-6] for the last three months.

Monitoring is a vital aspect of ensuring a consistent and competitive PSD2 ecosystem. FDATA members agree with the EBA that the CAs should have a primary role in the monitoring of KPIs in order to give TPPs confidence in the stability of the ecosystem and of ASPSPs’ dedicated interfaces. Below, we offer recommendations both on what to monitor and the means of doing so. as well as the schedule by which monitoring should occur.

Before discussing the monitoring schedule for ASPSPs, FDATA would make the wider point that much of the draft guidance issued in your consultation is relevant in the context of a mature ecosystem, which the current PSD2 market is not. At this point in time, FDATA recommend greater levels of monitoring to make sure that the market matures as quickly as possible and in time for the RTS deadline. FDATA agree with the EBA that a quarterly monitoring schedule would make sense once the market has come to maturity but would suggest far more frequent (weekly) monitoring until then.

FDATA refer back to our FDATA Proposed Exemption Criteria one to six and aim to briefly summarise how a CA would appropriately monitor each of these criteria:

● The PSD2 dedicated interface is widely available:
○ The CA benchmarks the PSD2 dedicated interface’s availability against the private dedicated interfaces, providing a clear pass/fail.

● The PSD2 dedicated interface is adequately responsive and maintains performance at scale:
○ The CA benchmarks an ASPSP’s PSD2 dedicated interfaces’ response times to those of the ASPSP’s private dedicated interfaces. If the response time of the PSD2 dedicated interface is significantly and consistently greater than the private dedicated interface then the PSD2 dedicated interface fails to perform at the necessary standard.This provides a clear pass/fail.

○ The CA runs the PSD2 dedicated interface through the minimum stress level(s) (described further in response to question 2) if the dedicated interface remains responsive and conformant during the CA testing the dedicated interface passes this criterion. This provides a clear pass/fail.
○ The CA in conjunction with the ASPSP overload the stress of the PSD2 dedicated interface. If the response to the stress overload are consistent and indicative of an overloaded system the dedicated interface passes this criterion. This provides a clear pass/fail.

● The PSD2 dedicated interface is unobstructive:
○ Where possible, CAs should engage with the TPP community in order to benchmark the sign-up rate of the PSD2 dedicated interfaces against the sign-up rate of credential-sharing through to screen-scraping. As these customer authentication journeys are like for like the the sign-up rate of credential-sharing through to screen-scraping provides a clear pass/fail. For the avoidance of doubt, customer sign-up rate via PSD2 dedicated interfaces should be greater than or equal to sign-up rate through credential-sharing through to screen-scraping.
○ The CAs run the authentication journeys through a customer experience checklist to assess conformance, providing a clear pass/fail. Further detail on the customer experience checklist is given in response to question 4.
○ The CAs analyse TPP complaints data and KPIs provided by the ASPSP and TPP to assess whether any unnecessary obstacles were created by the ASPSP.

● The PSD2 dedicated interface is conformant to the relevant specification:
○ The CAs make use of automated conformance testing suites to automatically test the dedicated interfaces’ technical implementation, providing a clear pass/fail. Conformance testing should be run several times an hour as the results will provide insight into the PSD2 dedicated interfaces availability.

● The account information/payment information data feed provided by the PSD2 dedicated interface is conformant, functional and complete:
○ The CAs make use of automated conformance testing suites to regularly (several times an hour) test the dedicated interface account information/payment information data feed, providing a clear pass/fail.
○ The CAs make use of automated conformance testing suites to provide clear indication of the content within the ASPSP’s account information/payment information data feed. The CAs then assess whether TPPs can store the data without significant hindrance. When assessing this criteria CAs should be aware that the TPP may already have received and stored data feeds for a PSU with the similar content, i.e. the same fields provided. This criteria provides a clear pass/fail.
○ The CAs make use of automated conformance testing suites to provide clear indication of the content within the ASPSP’s account information/payment information data feed. The CAs then assess whether TPPs can reasonably link this data feed to the respective PSU on the TPP’s interface. This criteria provides a clear pass/fail.
○ The CAs benchmark the content of the ASPSP’s account information/payment information data feed from the PSD2 dedicated interface against the content of data made available to the PSU via the ASPSP’s PSU interfaces. If the content of the PSD2 dedicated interface’s data feed is less than the content within the PSU interface’s data feed, then the ASPSP should not be granted an exemption. This provides a clear pass/fail.

● The PSD2 dedicated interface appropriately managed:
○ The CAs engage with the TPP community where possible and analyse TPP complaints data as well as KPIs from ASPSPs and TPPs to assess whether any inappropriate management has occurred.
○ The CAs provide a notification checklist that ASPSPs must conform to every time the ASPSP intends to make a change to the PSD2 dedicated interface that could result in a TPP requiring to make changes to their service. The notification checklist also notifies the relevant bodies of upcoming downtime, any changes to optional fields, . Further detail on the notification checklist is given in response to question 6.

ASPSPs often hold account information, and manage payment services, for millions of PSUs. An error (such as a PSD2 dedicated interface having a significantly delayed response time) lasting a couple of hours could cause severe customer consequence and likely lead to TPPs going out of business.

As a result, FDATA strongly urge the EBA to replace paragraph 25. We recommend that ASPSPs monitor PSD2 dedicated interfaces using similar practices to those currently established for monitoring private interfaces, and the statistics should be published to the relevant CA on a weekly basis. Crucially, any dispute addressing disparities in KPI reporting between TPPs and ASPSPs could result in a three month investigation period. FDATA deem this to be frankly unacceptable and will put millions of customers around Europe at risk.

Another wider point relevant here is that the vast majority of the draft guidance in your consultation focuses on ASPSPs self-attesting their conformance to their CAs. FDATA’s members do not think this method will produce the best outcome for accurately assessing conformance. We support the EBA view that ‘ASPSPs should have the same service level objectives and targets, contingency plans, monitoring and out-of-hours support for their dedicated interface as for the PSU interface’ contained in paragraph 18. However, FDATA highlight the inability for ASPSPs to objectively self-report; it is reasonable to suggest that there is significant ASPSP motivation to achieve an exemption. FDATA are therefore of the opinion that it would be naive to assume that ASPSPs would act in a transparent manner when KPIs are below target or if it is not in the ASPSP’s best interests to do so.

As such, FDATA’s recommendation is that CAs should consult TPPs for activity monitoring and cross-validate the results with ASPSPs, especially where inconsistencies are highlighted. This is a balanced and holistic approach which enables exposure to the TPP perspective of consumer data from PSD2 dedicated interfaces and utilise TPP expertise.

Question 4: Do you agree with the EBA’s assessments on obstacles, the options it considered and progressed or discarded, and the requirements proposed in Guideline 5? If not, please provide your reasoning.

Our answer here builds on our third recommended exemption criterion, that “the PSD2 dedicated interface is unobstructive”, with the key points being:

● PSUs’ adoption of the PSD2 dedicated interface is equivalent to or better than credential-sharing through to screen-scraping.

For PSD2 dedicated interfaces to be widely adopted, the authentication completion rate (the rate at which a PSU successfully completes an ASPSP’s authentication journey) must be better than or equivalent to credential-sharing through to screen-scraping. FDATA would like to stress the significance of this point and although it has been made by a range of TPPs across the PSD2 ecosystem and accepted by CAs, FDATA would strongly recommend it is adopted by the EBA in the regulation as a requisite criterion for an exemption.

CAs must be encouraged where possible to make use of TPP’s sign up rate data. Two widely tested FDATA members that are currently live in the UK AISP market have provided a snapshot of how a number of the UK’s largest ASPSPs are performing to date and it is reasonable to suggest that other TPPs will monitor these data closely as they are tied to the material success of their businesses.

PDS2 dedicated interfaces sign up rate against an alternative service’s benchmark, by ASPSP and TPP:
(please now refer to the bar chart on page 20 of the attached PDF)

Specifically, FDATA members strongly recommend replacing guideline 5 (d) with “PSUs’ adoption of the PSD2 dedicated interface is equivalent to or better than credential-sharing through to screen-scraping”. This meets TPP expectations from the legislation and means that CAs can measure sign up rates utilising TPPs data.

● The authentication journey conforms with the legislation.

An ASPSP’s PSD2 dedicated interface’s authentication journey must conform with the legislation. This provides TPPs absolute confidence that a part of their customer experience that they do not control (i.e. if and when their customer is redirected to their ASPSP) is sensibly designed and contains the right customer messaging such as to minimise PSU confusion and frustration.

To assess conformance in the authentication journey, FDATA strongly recommend CAs create a granular and simply-worded customer experience checklist referencing the relevant parts of the RTS and the EBA’s comments that authentication journeys need to abide by to conform. FDATA believe the customer experience checklist would add clarity to the TPP community as to what customer experience they should expect and would provide clear guidance to ASPSPs when creating these authentication journeys. This process has been adopted by the UK.

Sample from the UK customer experience checklist:
(please now refer to the table on page 21 of the attached PDF)

Within the checklist referenced above, there are two items FDATA would like to bring specifically to the EBA’s attention.

FDATA agree with the EBA’s assessment of guideline 5.2 (a), 5.2 (b) and 5.2 (c) and agree this should be added to the legislation to allow for a competitive ecosystem and future innovation.

Considering the methods of access available to a PSU, FDATA are grateful to and fully endorse the EBA’s opinion that:

“A PSU should be able to use the same authentication methods and procedures they use while accessing ASPSP channels directly, regardless of device or channel they use to interact with the TPP.” (EBA Opinion, para. 50)

FDATA would stress the value of such a statement to the TPP market by giving the three following examples. Note that all examples are taken from live PSD2 dedicated interfaces within the UK’s payments market.

1. The ASPSP has a more streamlined/frictionless authentication step when a PSU interacts with their mobile app than with the browser channel(s).

For example, an ASPSP that allows for biometrics authentication on the mobile app, however this functionality is not available through the web channel. It is realistic to expect in this scenario that PSUs who bank with the ASPSP will (in general) prefer the mobile app authentication method to the browser alternative. Making the mobile app authentication methods available to the TPP, regardless of whether the PSU is using a computer or any other device without the mobile app, could vastly help sign up rates and promote TPP adoption.

2. The ASPSP only has a mobile app and does not have a browser channel.

As PSUs are increasing their use of the mobile app banking, several ASPSPs in the UK only offer mobile app banking. Unless the ASPSP offers a decoupled flow as a method of access, in these circumstances, then any PSU using a computer (or any such device without the ASPSP’s mobile app) when interacting with the TPP, will not be able to allow the TPP access to their account information or manage payments. In such a scenario FDATA struggle to understand how the ASPSP would avoid an obstructive authentication journey without allowing decoupled as a method of access.

3. The device the PSU uses to interact with the TPP is not a mobile or computer device.

If ASPSPs allowed the decoupled method of access, TPPs would be able to interact with PSUs account information and manage payments using a device that is not a mobile or computer. Some common devices that are already used by TPPs to interact with users are:
a. Barcode readers;
b. Car number plate readers; and
c. Voice controlled speakers (smart speakers).

Without decoupled flows, a TPP would be restricted to computer and mobile device only. Unless all ASPSPs offer a decoupled method of access, a TPP’s capacity to innovate will be restricted to the devices offered by ASPSPs for use in their private channel(s). This in turn will limit the potential of PSD2.

As demonstrated by the above examples, allowing a PSU to access the ASPSP using the same authentication methods, regardless of the device they are using to interact with the TPP, is key to PSD2 success. A decoupled method of access must be available to allow this access.

Example 3 becomes particularly significant as any PSU who banks with an ASPSP that does not support a decoupled method of access would not be able to use a TPP that interacts with barcode readers. The example highlights that unless ASPSPs support a decoupled method of access, the TPP community is restricted in the devices it can use. The implications of example 3 must be considered carefully to allow for future innovation, and to make PSD2 the success it should be.

It is also worth considering a similar scenario where an ASPSP introduces a new authentication method (for example via voice control). This authentication mechanism would not be available to TPPs without a decoupled flow.

The points and examples above show that the statement:

“A PSU should be able to use the same authentication methods and procedures they use while accessing ASPSP channels directly, regardless of device or channel they use to interact with the TPP.” (EBA Opinion, para. 50)

Is equivalent to:

There is a requirement for all ASPSPs to support the decoupled method of access.

This interpretation of this requirement is common across several of the TPPs, CAs and ASPSPs in the EU. However, the collective view directly contradicts the EBA’s statement that a decoupled method of access is optional, so FDATA requests clarity on these contradicting points.

Specifically, FDATA members recommend the EBA explicitly stating that ASPSPs must provide both decoupled and redirect via deep-linking as methods of access to the PSD2 dedicated interfaces.

● The PSD2 dedicated interface does not require TPPs and PSUs to be subjected to unnecessary obstacles.

This recommendation can be broken down into two key and interrelated issues, the first being the impact of an increasingly obstructive customer journey or process caused by PSD2 and RTS legislation, and the second being the obstructive customer journey or process within the PSD2 dedicated interface that are not present with alternative services (credential-sharing through to screen-scraping).

Firstly, where TPPs face obstacles they were not subject to before PSD2, this will serve to restrict, as opposed to prime and encourage, competition. An obstructive journey will not only increase the difficulty of performing to an equal standard as the pre-RTS and PSD2 environment, but further hinder progress to improve and outperform these services in the interests of PSUs.

For TPPs requiring an ongoing connection, FDATA would like to explicitly state that 90 day re-authentication is the most significant obstacle.

Article 10(2) of the RTS states:

“for the purpose of paragraph 1, Payment Service Providers shall not be exempted from the application of SCA when any of the following condition is met:

(a) The payment service user is accessing online the information specified in paragraph 1 for the first time
(b) More than 90 days have elapsed since the last time the payment service user accessed online the information specified in paragraph 1(b) and strong customer authentication was applied.”

This means that the account information/payment information data feed agreed to by customers for the purpose of sign up and utilisation of a TPP service will require SCA every 90 days. This is an extremely high level of obstruction for a PSU to experience, and one which cannot be managed or mitigated by the TPP. This is likely to cause customer dissatisfaction as well as PSU and TPP complaints across the EU.

At this stage, FDATA would reiterate that the need for 90 day re-authentication for every PSU is unprecedented and as such, could vastly reduce TPPs ability to compete in the post-PSD2 environment. Unless these concerns are addressed, the outcome of PSD2 could come under serious jeopardy.

There are three key concerns FDATA and the wider TPP community have around the requirement for SCA every 90 days:

1. Unexpected customer journey
2. Negative user experience
3. Detriment to market competition

Legally mandating such obstacles in the TPP customer journey that are not present in ASPSP journey evokes a number of significant issues for TPPs. Contrary to the principles of the PSD2 regime, such provisions nullify the objectives of promoting healthy competition across the EU payments market. Such an interpretation of the RTS is inherently discriminatory against TPPs, and so will inevitably impact a TPPs economics. Such negative impact will not be shared by ASPSPs who have immediate leverage in the fact any product or offering will not experience the labour of the TPP customer journey. For example, where a TPP offers an overdraft facility to their customers, they would require the customer to re-authenticate every 90 days, whereas an ASPSP offering the same product would not.

This is in direct contravention of the principles of PSD2.

FDATA poses the question to the EBA of how TPPs are reasonably expected to engage in offering enhanced services in an a supposedly competitive space, where such an interpretation of the RTS is self-limiting in its benefit to TPPs. FDATA purports that such an implementation massively hinders the extent to which a level playing field can ever be achieved. We reiterate that such limitations are not currently being experienced by TPPs.

FDATA would urge the EBA to review Article 10(2) of the RTS. Unless significant changes are made, we deem it unlikely that the PSD2 initiative will achieve the purpose for which it was inaugurated.

FDATA members would highly recommend the EBA to review Article 10(2) of the RTS and remove the requirement for a PSU to authenticate using Strong Customer Authentication (SCA) every 90 days in order to continue using a service. There are a number of alternative suggestions FDATA would encourage the EBA to consider, and our membership welcomes the opportunity to discuss this point with the EBA further.

For the rest of the feedback to question 3, FDATA will assume that Article 10(2) of the RTS has been addressed as per the above. Due to this change, the statement:

‘The PSD2 dedicated interface does not require TPPs and PSUs to be subjected to unnecessary obstacles’

will become

‘The ASPSP has not added unnecessary obstacles to the PSD2 interface.’

This recommendation agrees with the RTS article 32 (3) and FDATA members go on to discuss methods for measuring unnecessary obstacles in response to question 3 and 7 and within our sixth recommended exemption criterion, “the PSD2 dedicate interface is appropriately managed”.

Question 5: Do you agree with the EBA’s assessments for design and testing, the options it considered and progressed or discarded, and the requirements proposed Guideline 6? If not, please provide your reasoning.

Our answer here builds on our fourth and fifth FDATA Proposed Exemption Criteria. Firstly exemption criteria four: “the PSD2 dedicated interface is conformant to the relevant specification designed by the CA.”

FDATA members disagree with the EBA’s guidelines 6.1. There are live tools for conformance testing that the PSD2 market has significantly benefited from. FDATA believe that a strong suite of conformance tools running multiple times an hour on dedicated interfaces are the only way that the interfaces can be monitored for conformance.

FDATA strongly recommend consideration for CAs to make use of these conformance tools as they provide an ongoing unbiased picture of conformance. Relying on specifications provided by the ASPSP and statistical reporting is not be enough to dictate technical conformance of PSD2 implementation.

We now move on to addressing exemption criterion five “the data feed provided by the PSD2 dedicated interface is conformant, functional and complete,” with the key points being:

● The data feed the PSD2 dedicated interface provides to TPPs conforms to the legislated specification designed by the relevant CAs.

The conformance suites FDATA recommend CAs adopting to test technical conformance will also provide a view on the conformance of an ASPSPs data feed. This adds further need for FDATA for conformance suite consideration.

● The implementation of the account information/payment information data feed provided by the PSD2 dedicated interface allows TPPs to store the data provided without adding hindrance.

Unless TPPs can perform basic functions i.e. store the data and dedupe the data feed provided by the PSD2 dedicated interface the interfaces will not be adopted.

FDATA disagree with the EBA’s findings in paragraph 49. For PSD2 to be widely adopted, CAs must analyse specific detail around how the design has been implemented above the legal requirements.

There is an example of a particular field within the UK’s PSD2 specification that FDATA feel justifies our opinion entirely.

The unique transaction ID field is an optional field within the UK Open Banking specifications. Since ASPSPs do not display unique transaction IDs to their customers (via private interfaces), the legislation does not require the ASPSPs to pass this field to the TPPs. However, by this omission, TPPs have considerable problems validating the uniqueness and immutability of transactions. Without unique transaction IDs, TPPs cannot be sure that the data they have stored for that PSU is correct and matches the ASPSP’s exactly. If an ASPSP does not provide the unique transaction ID field the ASPSP’s data feed does not perform the basic function required by TPPs.

This example gives a clear impression of a TPP requirement that is beyond the existing legal scope. The UK CA is aware of the unique transaction ID field and the problems TPPs will face if this field is not passed by the ASPSP. It follows that, when assessing whether an ASPSP is eligible for an exemption, CAs should use outputs of the conformance suite and look beyond the legal requirements.

In light of the example given above, FDATA members recommend that the EBA address paragraph 49 of the consultation paper.

● The implementation of the account information/payment information data feed provided by the PSD2 dedicated interface allows TPPs to link the data provided to the respective PSU within the TPP’s interface.

Another example of an optional field, this time EU-wide, that would severely degrade the functionality of PSD2 is Personal Account Holder Information (PAHI), provided by the ASPSP. PAHI is the only way a TPP can validate that their customer that authenticates with the ASPSP are who they say they are on the TPP’s interface. If an ASPSP does not provide a TPP with any PAHI the TPP has no idea as to who the authenticating PSU is. Unless TPPs can be reasonably certain as to the identity of the PSU, the PSD2 market is fundamentally non-functional.

Article 98 (d) of PSD2 mandated the EBA to develop regulatory technical standards on “the requirements for common and secure open standards of communication for the purpose of identification, authentication, notification, and information, as well as for the implementation of security measures, between account servicing payment service providers, payment initiation service providers, account information service providers, payers, payees and other payment service providers”.

Paragraph 27 of your Opinion on the implementation of the RTS on SCA and CSC is not compatible with the mandate of Article 98(d):

“Additionally, the EBA clarifies that the scope of data to be shared with AISPs and PISPs by the ASPSP under PSD2 and the RTS on SCA and CSC does not include the PSU’s identity (e.g. address, date of birth, social security number) given that those are not data that are necessary or requested to initiate a payment or access account information under PSD2.”

Your opinion suggests, and is indeed being interpreted as such in the UK, that ASPSPs do not need to provide TPPs with any indication of the PSU’s identity. This statement is untrue. If TPPs attempt to operate within the PSD2 ecosystem without ASPSPs providing indication as to a a PSUs identity, fraud is unavoidable and inevitable. It is worth stating clearly that these risks are avoidable and have only been made inevitable as a direct consequence of the the EBA’s opinion.

An example of the fraud risk introduced is given below:

Eve wants to use a TPP product with fraudulent intent, Eve knows John's personal details (name, address, date of birth). Eve fills out the TPP application with John's details and use her banking details to authenticate with an ASPSP. As the ASPSP has not provided the TPP with an indication of the PSU’s identity linked to the account information, the TPP now believes that John is the account holder and has no indication of any fraudulent activity. See the diagram below:
(please now refer to the diagram on page 28 of the attached PDF)

FDATA members in conjunction with the wider TPP community highly recommend the EBA address the statements made in paragraph 27 of the Opinion on the implementation of the RTS on SCA and CSC as a matter of urgency.

● The data feed the PSD2 dedicated interface provides to TPPs contains equivalent or more data than the data feed provided by the private interfaces.

While there is more data available through the private interfaces there is more data available via alternative services (credential-sharing through to screen-scraping). If this is the case, TPPs will be reluctant to use the PSD2 interfaces and requiring TPPs to migrate to such interfaces will restrict TPP’s ability to compete. The private interfaces allow the CAs and clear benchmark for completeness that the dedicated interfaces must match or better.

Again, we refer back to the comments made in paragraph 27 of the Opinion on the implementation of the RTS on SCA and CSC as a clear example of situation where an ASPSP will provide less information via the PSD2 dedicated interfaces than is available via credential-sharing through to screen-scraping. paragraph 27 directly results in the possibility of ASPSPs that provide a PSU identity information (PAHI, address, date of birth, social security number) on their private interface not providing this via the PSD2 dedicated interface. If an ASPSP were to follow this direction, which FDATA believe several EU ASPSPs will, the TPP community will do one of two things:

1. Be reluctant to move replace credential-sharing through to screen-scraping with the PSD2 dedicated interface, as the caveat of this will be that TPPs lose PSU identity information
2. Utilise the PSD2 dedicated interfaces and seek alternative services to provide PSU identity information

TPPs behaving in either of these ways could be extremely harmful for the outcome of PSD2 and PSUs across the EU, ss TPP reluctance to utilise dedicated interfaces will directly drive down PSD2 competition. Therefore, FDATA address the scenario where TPPs seek alternative services to provide PSU identity information. Due to the opinion piece suggesting PSU identity information is not account information or payment information, PSU identity information sits outside of PSD2 regulation. Therefore, unregulated services that screen-scrape a PSU identity information would arise. Any unregulated service comes with significant customer risk.

While there is possibility in ASPSPs providing less data via their PSD2 dedicated interfaces then by the private interfaces, there is a possibility for alternative services and unregulated markets. Clear harm could come to the EU payments market while this possibility exists.

The FDATA members are of the opinion that these implications were not meant by the EBA’s opinion piece and ask the EBA to review of paragraph 27 of the Opinion on the implementation of the RTS on SCA and CSC.

FDATA highly recommend the EBA address these harms by adding the following statement to the legislation:

The data feed the PSD2 dedicated interface provides to TPPs contains equivalent or more data than the data feed provided by the private interfaces.

Question 6: Do you agree with the EBA’s assessment for ‘widely used’, the options it considered and discarded, and the requirements proposed Guideline 7? If not, please provide your reasoning.

As previously stated we believe the term ‘widely used’ is too subjective to be useful and have already in a previous section proposed seven FDATA Proposed Exemption Criteria that would remove this subjectivity. We believe that if an ASPSP’s dedicated interface satisfies our seven FDATA Proposed Exemption Criteria then it will become widely used by TPPs. If an ASPSP’s dedicated interface does not satisfy all seven of the exemption criteria then it is not fit for purpose and will not become widely used by TPPs.
Therefore, we would deem an ASPSP’s dedicated interface ‘widely used’ if and only if the dedicated interface satisfies all seven of our FDATA Proposed Exemption Criteria.
This removes the need for an ASPSP to provide evidence that their dedicated interface is widely used. FDATA also feel that due to the unavoidable subjective nature of the term widely used by referring this term to the other terms in the RTS will only add clarity to the exemption process.

This matches the EBA’s opinion that defining widely used in a numerical figure is an illogical methodology.

FDATA Proposed Exemption Criteria
FDATA believe the criteria suggested below would be the same used by TPPs in evaluating whether to migrate services from screen-scraping to the use of dedicated interfaces. FDATA requests that any ASPSP’s dedicated interface satisfies the following criteria in order to be eligible for an exemption.

● The PSD2 dedicated interface is widely available
○ The uptime of the PSD2 dedicated interface is greater than or equal to the ASPSP’s private dedicated interface.

Further detail is given in response to Question 1

● The PSD2 dedicated interface is adequately responsive and maintains performance at scale
○ The response time of the PSD2 dedicated interface is quicker than or equal to the performance of an ASPSP’s private dedicated interface, at similar levels of stress; and
○ The PSD2 dedicated interface can endure similar levels of stress as the private interface can; and
○ If the PSD2 dedicated interface is unable to process TPP requests due to stress, consistent and conformant errors are provided to TPPs.

Further detail is given in response to Question 2

● The PSD2 dedicated interface is unobstructive
○ PSUs adoption of the PSD2 dedicated interface is equivalent to or better than credential-sharing through to screen-scraping; and
○ The authentication journey conforms with the legislation; and
○ The PSD2 dedicated interface does not require TPPs and PSUs to be exposed to unnecessary obstacles.

Further detail is given in response to Question 4

● The PSD2 dedicated interface is conformant to the relevant specification designed by the CA.

Further detail is given in response to Question 5

● The account information/payment information data feed provided by the PSD2 dedicated interface is conformant, functional and complete
○ The data feed the PSD2 dedicated interface provides to TPPs conforms to the legislated specification designed by the relevant CAs; and
○ The implementation of the account information/payment information data feed provided by the PSD2 dedicated interface allows TPPs to store the data provided without adding hindrance; and
○ The implementation of the account information/payment information data feed provided by the PSD2 dedicated interface allows TPPs to link the data provided to the respective PSU within the TPP’s interface; and
○ The data feed the PSD2 dedicated interface provides to TPPs contains equivalent or more data than the data feed provided by the private interfaces.

Further detail is given in response to Question 5

● The PSD2 dedicated interface is appropriately managed
○ Reported problems with PSD2 dedicated interfaces are addressed in a professional manner, similar to that shown to private dedicated interfaces; and
○ Appropriate notification is made available to TPPs in advance of any change made by an ASPSP where the change could cause an issue to the services a TPP provides to its customers.

Further detail is given in response to Question 7.

● The PSD2 dedicated interface is appropriately monitored providing confidence in stability
○ An ASPSP provides evidence that their PSD2 dedicated interface has passed the above six criteria for the last three months.

Further detail is given in response to Question 3.

Question 7: Do you agree with the EBAs assessment to use the service level targets and statistical data for the assessment of resolving problems without undue delay, the options it discarded, and the requirements proposed Guideline 8? If not, please provide your reasoning.

Our answer here builds on the sixth and final exemption criteria, that “the PSD2 dedicated interface is appropriately managed”, with the key results being:

● Reported problems with PSD2 dedicated interfaces are addressed in a professional manner, similar to that shown to private dedicated interfaces.

In order for PSD2 interfaces to be adopted by the TPP community, there is need for TPPs issues to be handled professionally.

FDATA strongly disagree with the EBA’s considerations on complaints data in paragraph 63 and the manner in which ecosystem problems are reported to the CAs, paragraph 62. For PSD2 to succeed, TPPs will have to rely on the stability and functionality of ASPSP platforms. Consequently, expecting CAs to use only statistical data provided by ASPSPs with the ASPSP’s perspective of their resolution of problems is dangerous.

The key concerns FDATA have over the proposals in paragraphs 62 and 63 are:

1. Severity is much better assessed by TPPs then by ASPSPs;
2. TPPs may disagree that an ASPSP has resolved a problem in an appropriate and quick manner;
3. Any issues that TPPs incur and are required to develop solutions for in response to tweaks and changes made by ASPSPs are not being reported; and
4. As ASPSPs are highly motivated to obtain an exemption, solely relying on statistical data the ASPSP supplies and allow the ASPSP interpretations to impact this statistical data, could lead to discriminatory practices with respect to the TPPs.

There are several examples of the issue raised in the second point above having occurred in the UK so far.

Specifically, when resolving a technical issue, Europe’s largest ASPSP (HSBC) severed the consents and access of all their customers to the TPPs the customer’s were linked to. The TPP community saw this as the most severe action HSBC could take to harm the PSD2 ecosystem. By the ASPSP taking this action, significant customer experience issues occurred alongside economic losses to several TPPs. This technical issue was reported as fixed without delay by HSBC. This fix would not be and has not been accepted by the TPP community and a number of TPPs are considering legal action against HSBC.

By discounting complaints data and relying on a statistical data provided by the ASPSP this event could be seen as ideal practice. Until this possibility is removed TPPs will be very hesitant to move on to PSD2 dedicated interfaces.

As seen in our feedback throughout this document, FDATA encourage the EBA to recommend CAs to make use of the TPP community where they are able. This should provide additional insight into whether ASPSPs are resolving problems without undue delay, allow CAs to cross reference KPIs and which will only serve to benefit the ecosystem as a whole.

● Appropriate notification is made available to TPPs in advance of any change made by an ASPSP where the change could cause an issue to the services a TPP provides to its customers.

Almost any change an ASPSP makes to the PSD2 dedicated interface could cause TPPs to make changes to their internal software. Unless ample warning and a detailed notification is provided of planned upcoming changes to the PSD2 dedicated interfaces, the PSD2 ecosystem risks significant TPP and PSU frustration.

To quantify ample warning and detailed notifications, FDATA strongly recommend that CAs create a granular and simply-worded notification checklist that ASPSPs must follow in order to show appropriate management. Similarly to the customer experience checklist, FDATA believe the notification checklist would add clarity for the TPP community as to what processes they need to put in place to mitigate PSU frustration and provide clear guidance for ASPSPs to follow in order to provide appropriate management of the PSD2 dedicated interfaces. This process has been adopted by the UK and the notification checklist is currently being developed by OBIE.

Sample from the UK notification checklist:
(please now refer to the table on page 33 of the attached PDF)

Question 8: Do you agree with the proposed Guideline 9 and the information submitted to the EBA in the Assessment Form in the Annex? If not, please provide your reasoning.

FDATA agree in general that the assessment form is a suitable way to document the exemption procedure.

FDATA tentatively suggest the assessment form could reflect a breakdown of the criteria required for an exemption (referenced in the summary and response to question 6). FDATA suggest the following assessment form:
(please now refer to the table on pages 34 and 35 of the attached PDF)

If the answers to all the seven subpoints 7 (a) – 7 (f) is yes then the ASPSP is granted an exemption.

This should benefit an ASPSP seeking an exemption in two ways:
1. It adds further clarity on the set of minimum standards required to get an exemption; and
2. Provides more granular detail to an exemption refusal. The more detail on these refusals could only be beneficial to the ecosystem as it removes the possibility of invalid interpretations.

This is not one of FDATA’s key concerns for the outcome of the consultation paper.

Question 9: Do you have any particular concerns regarding the envisaged timelines for ASPSPs to meet the requirements set out in these Guidelines prior to the September 2019 deadline, including providing the technical specifications and testing facilities in advance of the March 2019 deadline?

Firstly, FDATA feel strongly that the deadlines set by which the RTS must be implemented will not be met by over 90% of EU ASPSPs, including the largest banks in the EU. In part, this is due to their resistant adoption of guidelines and rules imposed by the CA, and also due to their rigid and archaic systems that seem to inhibit change.

The risk associated with ASPSPs not meeting their deadlines is incredibly high. For example, one FDATA member customers rely on the service it provides as an external overdraft, as an addition to their bank account. If the deadline arrives and this member’s current practices (credential-sharing through to screen-scraping) are no longer available, its 350,000 customers could be at risk of losing services on which they rely. This is true of all TPPs that currently utilise credential-sharing through to screen-scraping; all companies would be affected, as well as the millions of consumers they serve across the EU.

FDATA highly recommends, as a matter of urgency, a review of the current state of the PSD2 ecosystem. The initiative has been live for approximately 7 months and RTS requirements come into effect in almost 13 months’ time. The time constraints should allow CAs to form an informed and accurate view of whether, on the whole, ASPSPs will be able to deliver a stable, conformant and preferable alternative by September 2019. If CAs agree with the opinion FDATA hold, that by September 2019 the majority of ASPSPs will not be able to offer a feasible PSD2 interface, we highly recommend adjusting the timelines to take this into account. We recommend the RTS timelines are pushed back by 12 months as this will also focus ASPSPs’ attention on building technical conformance into their live environment, rather than relying on their test facility as a means of compliance.

FDATA would also like to briefly raise concerns from its membership of the possibility of CAs having adverse incentives to give ASPSPs under their regulation exemptions. If such concerns are valid, this add significantly to the risks and the imbalance of PSD2 ecosystem. These recommendations to postpone RTS deadlines should reduce the number of PSD2 dedicated interfaces in the live TPP environment which are unfit for purpose, so mitigating the negative consequences.

FDATA also add that given that implementing the decoupled method of access could be a vast undertaking for both ASPSPs and TPPs alike, FDATA would like to express the need for the EBA to provide clarification on the issue of timelines as soon as possible.

Finally, FDATA agree strongly with the comments in paragraph 72.

Question 10: Do you agree with the level of detail set out in the draft Guidelines as proposed in this Consultation Paper or would you have expected either more or less detailed requirements on a particular aspect? Please provide your reasoning.

Considering that FDATA have recommended an alternative set of FDATA Proposed Exemption Criteria and explored in some detail the manner in which a CA could realistically and appropriately measure the success of each criterion, we believe this question is no longer relevant.

Name of organisation

Financial Data and Technology Association