MAIF

AIS players welcome the publication of the EBA’s draft Regulatory Technical Standards specifying the requirements on strong customer authentication and common and secure communication under PSD2. We appreciate the opportunity to contribute to their drafting, in order to ensure a level playing field among all actors.
The draft RTS states that the first AISP connection requires strong authentication. This is not the current situation for our business, but we accept this security measure because we understand its usefulness in order to strengthen the security for the first connection of the user.
However, the draft RTS imposes the permission to access accounts by AISP to be renewed every 30 days with strong authentication for each user of AISP and bank. This will impose a strong constraint on the users and radically change their experience of the service they subscribe. Unlike banks, AISP are not unavoidable: customers freely decide to use our services in order to have rapid, exhaustive, reliable information on their accounts with a minimum level of intervention from them. This is the core of our services to our customers and the very reason why we were able to grow.
This new obligation also causes an imbalance compared to banks. Indeed, the draft RTS does not impose to them the same obligation in terms of strong authentication when the client has direct access to his accounts through the bank interface. Therefore, banks will be able without interruption, to push information to customers while AISPs will no longer be able to provide this service.
This creates a distortion between banks and AISP and therefore contradicts the objectives of the PSD2. Indeed, a user with two AISPs and three banks, will have to comply with six strong authentications per month to connect to his accounts via his AISP. Meanwhile, that same user would have no strong authentication to access online his bank.
We would like to underline that a very recurrent authentication is a radical disincentive for the use of AIS. Several statistics from AISPs currently operating on the market support this:
• Between +600% and +3300% loss of users in France, after a year, for users who were subjected to a simple but regular system of passwords or regular strong authentication.
• To the best of our knowledge, no AISP were able to develop in Belgium and Italy, two countries where banks require strong authentication for each connection.
This shows that regular strong authentication would have a fatal impact on the use of AISP, as well as on the conditions for a fair competition and for innovation.
Moreover, this regular strong authentication seems disproportionate compared to SEPA Direct Debits or EBICS access to business accounts which have no limit in terms of time, but can be removed at any time at the user’s request.
We ask that after a strong authentication for the first connection by the AISP, the access to the account would be without any limitation over the time.
In order to both respect the spirit of the PSD2 and to fully secure the users, we propose that the initial strong authentication will be dynamically linked to the user and to an account with the AISP. This strong authentication should allow the AISP to obtain a username and a non-replayable security token. For every connection, the AISP sends the username and the non-replayable token.
The bank, after verification of the token, creates a new token and includes it in its response. This token must absolutely be valid on the online interface of the bank. As this non-replayable token is changed at every new connection, it would immediately identify and stop any hacking attempt without waiting 30 days of strong authentication and without imposing a restriction on the customer’s usage. Indeed, in case of the hacking of non replayable token, the same token will be used by the hacker and the AISP, which would result in the invalidation of the AISP access on this account.
In order to increase security and transparency, we suggest that the user can view at any moment on the interfaces of AISP and his banks the authorizations given to AISP and can dismiss them at any time.
Finally, we ask that exemptions must be applied to all AISPs. The draft RTS proposes that strong authentication exemptions may be - or not - applied by banks. This creates a legal vacuum. Yet, AISPs needs to know that they will be able to provide their service and to access to accounts. Allowing banks not to apply the exemptions without justification represents a major risk to AISPs, as this could end up with strong authentication for each connection that the banks would have arbitrarily decided.
NA
NA
AIS players welcome the proposal made in the RTS to ensure exemptions from the application of Article 97 on strong customer authentication and on security measure. We agree with the EBA’s approach to propose a clear list of specific exemptions defined in Chapter 2 of the draft RTS, in which PSPs are not obliged to apply strong customer authentication. This option will allow the development for user-friendly and accessible means of payments for low-risk payments and ensure a truly valuable level-playing-field among market participants.
However, we would like to validate our understanding of the draft RTS and to confirm with the EBA that this principle of exemption is mandatory as explained in recital 55 “EBA is seeking views from respondents to the CP as to whether the proposed list of exemptions would also be compatible with a potential scenario whereby exemptions would be mandatory for the ASPSPs, meaning that ASPSPs would be prevented from implementing SCA on transactions that meet the criteria for exemption.”.
Mandatory application of exemption would acknowledge the specific nature of AIS.
NA
NA
AIS players welcome the objective fulfilled in the draft RTS to ensure that dedicated interface of the ASPSPs will work properly and provide the same level of service as their online banking platform. Yet we believe that the RTS does not provide a sufficient clarity on two points: the framework and the free access.
Firstly, the draft RTS proposes that banks provide open and documented interfaces to access to the accounts. We support this proposal. However, the draft states that if a dedicated interface is offered by the bank, the AISP must necessarily use it. This proposal is not acceptable.
Today, French AISPs use the online banking" interfaces of banks. The quality of service of these interfaces is good and allows us to have the same level of information and reliability that applications provided by the banks, which meets the objectives of the PSD2. According to us, connecting through the official website of the banks is the most effective and secured way to get updated, valid and accessible information that are necessary for AIS to provide our services.
We understand that the EBA would like to propose an alternative. But, we would like to underline that some banks may (for reasons of cost, time, priorities) not want to immediately develop dedicated interfaces and will be under pressure to do something quickly and without warranty of quality.
Facts show that a dedicated interface must be made reliable over time, and a lack of reliability even for few hours, is fatal to the user confidence in the services of AISP. French AISP have used dedicated interfaces (API type) made available by the French banks. The results are concerning. Indeed, we experienced services breakdown up to two weeks, which destroyed the user’s confidence in the service provided by the AISP, even if these errors were not AISP’s fault. Moreover, some errors have simply never been resolved, preventing any equal access to data to be a reality. This terrible experience had a direct impact for our business model, as the user (our customer) thinks this is the AIS responsibility.
In the past, banks have tried to curb the development of AISP and PISP, seen as competitors. The future RTS needs to avoid any element that would help banks to have a competitive advantage over AISP.
We are in favour of the development of APIs in the banking sector. But we believe it will require time before these APIs could provide the same level of service as the current online banking interfaces with proven reliability. Being forced to use a new interface could lead to a regression for the user in terms of level of information or service offered. Indeed, in the hypothesis of an imposed access, if we would have to wait more than a few minutes for the resolution of an access problem, or even worse, wait for the investigation of a complaint, our AISP will lose, immediately and irrevocably, all their clients. The draft RTS also raises the question about the entity that would judge that the same level of service is provided and the time that would be needed to investigate a complaint.
In parallel, there are simple systems to authenticate AISP from banks on the online interface. For instance, IP addresses are currently used by banks to identify AISPs which connect to their online interfaces.
Moreover, the PSD2 explicitly mentions that the RTS should be technologically neutral and on economic models (Article 87a- "to Ensure technology and business model neutrality"). However, this obligation is contrary to that article since the AISP will have to abandon their technological innovations - that proved their reliability for years - for unproved technologies that will be newly offered by banks.
Therefore, it is essential to have a choice between using direct “online” accesses of the banks or the dedicated accesses.
We propose that AIS and banks can use the interface of their choice, either the online banking interface or the dedicated new interface via an API, during a probationary period during which each bank is free to choose how it would guarantee the access and - in the same time - AISPs are free to choose their connection method. During this period, supervisory authorities can run all the necessary checks on the quality of service and collect any complaints, without either stopping the innovation or endanger the survival of AISP. At the end of the probationary period, the supervisory authorities will check out the best solutions that were freely implemented on the market. We also believe that imposing a fine to ASPSPs that would not correctly ensure the maintenance of the dedicated interface on the long run, would create a financial incentive to comply with the RTS.

On the issue of the costs, we understand in this that this interface (direct or dedicated) will be provided to AISP without any cost. We wish to have a written confirmation on that specific point and to ensure that the bank cannot create a special payable option for its customers to use this interface, which would be against the neutrality on economic models and could simply close access to AISP and PISP. This seems logical as the PSD2 states that the use of the interface access to bank accounts will be possible without contractual relationship between AISP or PSIP and the bank (Article 66/5 and s.67 / 4 of the PSD2.). We do not understand how a price could be applied without contract but we would appreciate more clarity on this issue.
We therefore propose a clear and explicit wording of the free access to information for AISP and PSIP."
NA
NA
As AIS, the service we provide to our customers is to inform them about their finances. In order to provide tools and features that help people managing money, AIS Players need to retrieve regularly data related to money activities on bank accounts. But, the RTS project does not support this as they specify that AISP can access the user accounts only twice a day. This proposal is hardly acceptable for AIS.
Indeed, our global economy is moving more and more toward real-time information and real-time services. And imposing such limitation would give an advantage to banks which have an unlimited access and then creates a clear imbalance in economic models. This advantage given to banks would only be strengthened with the development of real-time payments which is not compatible with a daily limit, and goes against the spirit of creating a level-playing-field among all actors.
Likewise, this limit will be obsolete at the time of its implementation: in fact, consumers’ uses are moving towards real time, as well as regulations. Indeed, national instant payment solutions have been successfully launched in a few Single Euro Payments Area (SEPA) countries (such as Denmark, Poland, Sweden and the UK). Moreover, a SEPA Instant Credit Transfer (SCT Inst) scheme is scheduled to be published in November 2016. The limit imposed in the draft RTS seems to run counter to the newest evolutions in financial services.
We understand that multiplying accesses in order to detect as soon as possible new user operations is not a viable solution. That would create an overload on the bank interface as well as the AISP infrastructure.
We want a virtuous dynamic to be implemented in the RTS framework: access should not be limited for AISP and banks should be encouraged to develop reporting systems to AISP to inform them of any new operation. AISP will willingly limit the number of access if we receive notifications.
Section 98 of the PSD2 1d clarifies the notion of notification applicable requirements for common open standards and secure communication for the purposes of identification, authentication, notification and information". Interests of AISP and banks are aligned in accordance with the objectives of the PSD2. Such solution would respect the objective of the PSD2 and ensure the efficiency of our service that gives customers a better empowerment over the management of their money and savings."
[Other "]"
Financial services institution - Registered in the Registre des représentants d'intérêt de la Commission Européenne under the identification number 62975755109-62
[Other"]"
Financial services provider including AISP activity
Thierry COURET