In terms of Account Information Services (AIS) and Account Information Service Providers (AISP) the following has to be noted. The AISP is the provider that gives AIS to the PSU. The AISP can be independent from the ASPSP hosting the payment accounts, or it can be a service provided by the ASPSP. The electronic banking provided by an ASPSP (“direct online access to payment accounts” in the RTS) is an AISP for all purposes of PSD2 and for all purposes of the RTS. Consequently, in order to fulfil the neutrality and level playing field aimed by PSD2, all measures imposed to AISP have to be fulfilled by both independent AISP and by the AIS provided by an ASPSP. So for all the questions we will keep in mind that the provisions proposed have to be neutral and provide a level playing field between independent AISP and AIS provided by the ASPSP which is the purpose of PSD2 in regards to AIS. Any provisions that do not guarantee neutrality or a level playing field, now or in the future, will have to be amended in the shortest possible time since they are identified.
Also, we feel that the current state of the RTS is still not ready to for us to provide competent answers to many of the requested questions. We urge the EBA to provide another round of consultation for us and other parties to provide answers to again.
See more comments on this question in the answer to question 4.
We appreciate that EBA is trying to facilitate user-friendly and accessible solutions in line with what’s stated in PSD2. Unfortunately, the proposed solution will achieve nothing of that and will, compared to the most widely used set-ups today, be a major set-back, making it far more complicated to use an AIS service.
Problems with the proposed model:
1. Forced multiple different SCA makes AIS inaccessible
2. Model is not technology-neutral
1. Forced multiple different SCA makes AIS inaccessible
Having multiple banks have for a long time been complicated and time consuming. Part of the reason has been the need to login to different bank interfaces and use different authentication methods. AIS are solving that by making it get an aggregated view by just logging in the AIS. This seamless experience has in most cases been created based on the absence of strong customer authentication and secure storage of static username and password.
Many users of AIS services have more than 5 different financial suppliers (ranging from niche providers of savings, credit, mortgage products etc. to main-street banks). Forcing each user to, once per month, to find 5 different key fobs/SMS codes/code cards just to access the AIS would make the AIS highly inaccessible and far from user friendly. While that would be problematic for most industries, this happens to be the most valued features for the AIS industry. As PSD2 strongly stresses the importance of easy access and simple, consumer friendly experience, it is surprising to see a proposal so far from that.
- SCA only the first time a ASPSP is linked to the AIS
- The AIS should make it simple for the user to turn-off automatic aggregation of data in the AIS customer interface.
- The user should also be able to contact the AIS (e.g. via e-mail) and request the AIS to stop aggregating data.
2. Model is not technology-neutral
The option for AIS to aggregate data when user is not active is a prerequisite for equal access to data between AIS and ASPSP (see 2. above) and we understand that EBA want to facilitate this. Unfortunately the suggested method is not technology-neutral, nor future proof and with a number of options for the ASPSP to avoid this.
The set-up suggested by EBA works with authentication methods that is used in only some European countries. The two most common examples:
- ASPSPs rely on single factor password → AIS store the password
- ASPSPs use SCA with a combination of device pinning and password → the AIS pin their servers and store the password
There are however numerous authorization process that is not compatible with the EBA suggestion
- Device pinning with limitation on number of devices that can be pinned (used by a major Swedish bank)
- Device pinning where only the user’s own phone can be pinned (used by a major Swedish bank)
The outcome in the above examples is that the ASPSP always has real-time access to data (server-side) and can send push notifications to the user whenever something important happens. The authentication is smooth as the end-user only enters a pin-code once (device already pinned) to enter the ASPSP’s app.
The AIS however has no access to data unless the user triggers aggregation i.e can’t be proactive. The end-user also need to do SCA for e.g. 5 different ASPSP when entering the AIS i.e. making the AIS highly inaccessible.
Overall the most important thing for us is the AIS/PIS is treated equally to the banks own app. This goes for all proposed data standards, authentication requirements, access to data etc.
- The continuous information aggregation by AIS from ASPSP cannot be built upon the ASPSP end-users SCA procedures and the exception for SCA for AIS cannot be optional but needs to be mandatory
- The end-user shall only perform SCA towards the ASPSP the first time she adds the ASPSP to the AIS
- When AIS has a valid certificate that verifies their identity towards the ASPSP (i.e not dependent on existence of static passwords) they are allowed to continuously aggregate data.
Not at all. We’re deeply concerned, and surprised, with the provision that forces AIS and PIS to use indirect access (dedicated interfaces) where ASPS can cripple the AIS industry by restricting the information flow and communication.
The PSD2 states that the ASPSPs, which are providing a mechanism for indirect access, will need to also provide direct access AIS and PIS. In addition, Recital 93 states that AIS and PIS should be allowed to provide their services without restrictions from the ASPSPs, no matter if it is direct or indirect access, and that a legal framework should be created to ensure this. The point being that ASPSPs should not be able to control the AIS and PIS. The circumstances under which the ASPSPs can deny, or block, the AIS and PIS are if these conduct unauthorized or fraudulent access, as stated in Article 68 PSD2.
Direct access is the only way to make sure that AIS and PIS technical performance can be on the same level as the ASPSPs. Without this access right it will not be possible for the AIS and PIS to compete on fair terms with the ASPSPs.
The RTS on the other hand states, in section 69 a) (page 20) and Recital 11 (page 27), that AIS and PIS should be directed to use a dedicated interface, which is decided upon by the ASPSP. In addition article 19 (3) states that a particular message format, ISO 20022, needs to be used which is not compatible with direct access.
Why it’s wrong to force the use of dedicated interface on TPPs
Section 64 (page 19) of the RTS states the reasons for implementing a dedicated interface. Apart from disallowing direct access, as will be described later, we below point out why a dedicated interface in itself is the wrong way to go.
Banks would control the data to TPPs
- In Section 69 a) (page 20) of the RTS EBA suggests that “ASPSP shall offer at least one communication interface enabling secure communication with AISPs, PISPs and PSPs”. This suggests that the development of a communication interface is given solely to the ASPSP, and hence that the TPPs would need to adapt to each ASPSPs interface and the information included by the ASPSPs. As it would be a separate interface from the online/mobile platform there would, or could, be differences between the two. The result of such would be that the ASPSPs would be able to decide which information to include and what to exclude. It is not given that the two would show the same information, and unless the online platform and the dedicated interface are one and the same the ASPSPs have the power to make distinctions between the two. The definition of “Payment Account” is vague and leave plenty of room for interpretation. Rest assure that banks will use this to their advantage, excluding information from accounts which for the consumers are on less favorable terms and thereby avoiding increased competition.
The control of the interface would mean a great advantage for the ASPSPs as they will be able to control the information flow to the TPPs. Important to keep in mind is that the TPPs are regarded as competitors by the ASPSPs as they bring transparency and competition to the banking market. The AIS industry has been also suppressed by the banking sector for almost a decade with threats, blockings and lawsuits throughout Europe. To give the ASPSPs the control over the interface would mean a great risk to TPPs.
Bank will have all incentives to let the dedicated interface perform poorly
- Another real concern with a dedicated interface controlled and managed by the ASPSPs is the performance of such, and that the ASPSPs won’t invest enough resources in to such interface. Even if this is pointed out by the EBA in Section 65 of the RTS, we do not see a clear solution to this issue. Section 69 d) suggest that the “ASPSPs shall ensure that their communication interface is offering the same functionalities and the same level of availability, including support, as the online platform”, but that is not a clear enough solution.
Apart from the risk of inadequate performance and support there is also a risk that a dedicated interface would not support the newest functionalities, or at least not with the same speed as in the online platform.
- To develop and maintain an additional interface has no added value for the ASPSPs and hence will be a low priority. Maintaining a dedicated interface, apart from the online platform, would, for the ASPSPs, mean to invest in additional resources to keep such an interface functioning. As a dedicated interface won’t be needed for the ASPSPs to run their own business it will not give any additional value to them and hence only be a cost for the ASPSPs. The additional value created for the ASPSPs will be non-existent and therefore the ASPSPs will not have any motivation to manage and maintain a dedicated interface. On the contrary, there will be strong motivations for the ASPSPs to keep the service level and functionality of the interface as low as possible, in order to keep non value adding resources to a minimum.
Banks will be the ones interpreting the law- TPPs won’t stand a chance to complain
- From section 69 d) of the RTS the EBA states that the ASPSPs will be obligated to make sure the dedicated interface “would offer the same service level as the online banking platform of the ASPSP”. This is a very vague formulation as “the same level” would be subject for interpretation. Furthermore, it is suggested by the EBA in the same section that this would be “addressing the concerns that AIS/PIS providers have raised in their response to the DP in relation to the potential lack of availability or the lack of resources invested by the ASPSPs to maintain and/or to provide technical support for addressing such dedicated interface”, and hence would solve the problems as described in points 1 and 2 above. We cannot see that this suggestion solves any of these problems. To maintain “the same level” would be subject to interpretation and opens up for different views and opinions on what the “same level” would mean.
This leaves a large gap and uncertainty about the governance. Even if there would be a collectively agreed definition of “the same level” it would be very complex to monitor, and it is unclear who would determine if it has been maintained. It also implies that there would be a governing authority to monitor and rule if the same level has been maintained. Again it is important to keep in mind that the ASPSPs has everything to gain by providing as low level as possible for the dedicated interface towards the ASPSPs. What will happen if the ASPSPs are not maintaining the same level? Again the ASPSPs have all to gain by providing as little as possible while it would most likely be extremely damaging to the TPPs to not get access to the needed date, as it would destroy their entire business.
- In case the ASPSPs are non-compliant in their obligation to provide the adequate level of functionalities and support to the dedicated interface, it seems that the only way would be to engage in a legal battle with the ASPSPs. As most of the TPPs are fairly new and smaller companies while the ASPSPs in many cases are giants with vast resources, it is not reasonable to assume that the TPPs should file a lawsuit, or file a complaint to a governing authority, as soon as the ASPSPs are not compliant. The TPPs won’t have the resources to have drawn out legal conflicts with the ASPSPs. Again the advantage would solely be with the ASPSPs as they have resources to maintain such legal conflicts over a prolonged period of time, while the TPPs in most cases don’t.
Why we disagree with EBA’s rationale
In Section 69 of the RTS, EBA are suggesting to introduce a dedicated interface replacing the direct access. We believe that this is the wrong way to go. Below we will explain why it is wrong to disallow direct access and why the arguments for introducing a dedicated interface are flawed.
The arguments EBA use to rationalize why it mandates TPPs to use dedicated interfaces (indirect access) and disallows direct access are two; first it argues that if would be easier for competent authorities and ASPSPs to control and track access, and secondly, that it would be problematic for TPPs to discover on their own how to integrate with each ASPSP.
We believe that both of these arguments are flawed:
- First, the argument that it would be problematic to track and control access to ASPSPs by TPPs is simply not true. First, as outlined in Article 20 of the RTS, TPPs will have identify itself, specifically proposed using certificates, towards the ASPSPs. This means of identification, like many others, are directly compatible with direct access and allows the ASPSPs to easily track and control a communication session initiated by a TTP, rather than a PSU.
Secondly, as empirical evidence, Tink is currently identifying sessions initiated on behalf of PSUs to the ASPSP, and the majority of these ASPSPs already today use this identification to track and control the direct access employed by Tink, where Tink as a TPP access the customer channels of the ASPSPs through their mobile APIs.
- The second argument regarding TPPs finding it problematic to discover on their own how the direct access channels of ASPSPs work, is first and foremost an argument as to why it could make sense for ASPSPs to create a standardized dedicated interface, but not an argument as to EBA transgressing its PSD2 mandate and outlaw direct access.
As to the argument itself, firstly, as both stated in the paragraph 64 of the background to the RTS and in the Article 19 (4) of the RTS, ASPSP would be mandated to provide documentation for any such interface for TPPs to implement, which means it would not be up to the TPP to discover on their own how the ASPSPs interfaces work at all.
Secondly, also empirical evidence, the fact that we already today have a thriving and functional market with a large number of active TPPs, both on the PIS and AIS side, should more than enough illustrate that the problem the argument tries to portray, is simply not true, as all the current TPPs already have manage to create a thriving and innovative industry, even without said documentation.
We don’t see a reason for mandating the use of a dedicated interface and outlawing the direct access model, as the current model with direct access is already working well.
Mandating TPPs to use any dedicated interface and outlawing the direct access model poses a clear and present danger to the AIS and PIS industries. For the PSD2 to not completely destroy these industries, the direct access model must be allowed to continue and it should be up to the market to decide if the dedicated interface as constructed by the ASPSP provides a better way to interface with the ASPSP or not.
If a dedicated interface is implemented by the banks we believe that the required performance of the dedicated interface must be elaborated and explained in detail by the EBA. For example it must be stated what “the same level” means and what it is that should be on the same level, which parts of the infrastructure that should be on the same level.
We strongly suggest that it is clearly stated that the dedicated interface must make sure that the TPPs backend can perform on the same level as the ASPSPs backend. Meaning that there should not be any discrepancies in terms of availability and speed of the PSU data between ASPSPs backend and that available to the AIS backend. It is not enough that the dedicated interface is on the same level as the ASPSPs frontend, e.g. the ASPSPs app, as there could lead to vast performance differences.
No. The suggestion of mandating that interfaces use ISO20022, goes against even EBAs own argument about not prescribing specific industry standards to be complied with, or listing specific technological solutions, which we most certainly agree with; would limit innovation going forward by strictly defining and limiting the information flow and
ISO20022 would be very limiting in terms of the products, services and infrastructure that would be a result of a real technology neutral regulation, allowing open innovation. The ISO20022 standard suggestion specifically has a number of particular issues. Primarily, the ISO20022 standardization body is notably comprised of members which are the incumbent banks and the incumbent payment networks. Having an industry organization responsible for defining the type of information that AIS and IPS actors can access, steered by the same banks who for decades have actively worked against the smaller AIS and PIS actors is completely counter productive and goes against the entire purpose of PSD2.
The interoperability argument that the EBA uses as a rationale for imposing ISO20022 is simply not true and is evidenced by the flourishing AIS and PIS industries we have today which are fully interoperable, and imposing the use of ISO20022 can simply not be understood.
More importantly, mandating the use of ISO20022 elements means that EBA is transgressing its mandate by indirectly outlawing direct access as stipulated by recital 32 PSD2 (see answer to Q7 above) as direct access interfaces used today does not implement ISO20022 elements, for the very natural reason that they are not relevant in the context of payment initiation, in contrast to its original purpose to serve as a common message format for bank-to-bank messaging. Unless the ASPS is imposing on the PSU to communicate with the ASPS using ISO20022, TPPs should not be limited by that requirement.
No. Having access to real-time data is already today a major competitive advantage for the ASPSP compared to the AIS. Both ASPSP apps and AIS apps are becoming increasingly pro-active and just-in-time e.g sending push notifications with information as “you just got paid”, “balance is low” or “suspicious transaction” that triggers usage of the apps. A/B test from AIS shows that monthly usage is up on average 200% when these highly relevant notifications can be sent out. Hence giving ASPSP access to real-time data while limiting AIS to refresh data 2 times per day is giving ASPSPs a major unfair competitive advantage.
The argument that aggregating data multiple times per day impose a significant load and cost for ASPS should be scrutinized. Any fairly modern bank API can answer an API-call with virtually zero marginal cost, and there are numerous de-facto industry standards to support the use case where the ASPSP would push data in real time to AIS if the user has authorized the ASPSP to do so (using SCA).
Data can be aggregated by AIS 24 times/day but if the ASPSP leverages real-time access/push notifications to the PSU via the ASPSP’s app, the same must be facilitated by the ASPSP to the AIS. AIS shall be able to aggregated data if 1) end users has authorized this via SCA when adding the ASPSP 2) AIS has a valid certificate that verifies their identity vs the ASPSP (i.e not dependent on existence of static passwords).