Response to discussion on RTS on strong customer authentication and secure communication under PSD2
Go back
It has to be noted that to develop the use of AIS, it is necessary that AIS and PIS providers have access to the set of data to which the user has access to via his banking connection. The object of the future RTS will then be to en-sure to AIS and PIS the access to those data by protecting the final user from the phishing or other fraudulent practices.
Furthermore, the term of “other abuses” seems to be particularly wide and should be clarified as to which kind of abuses the articles relates to.
Indeed, “Member States shall ensure that a payment service provider applies strong customer authentication where the payer :
(a) accesses its payment account online ;
(b) initiates an electronic payment transaction ;
(c) carries out any action through a remote channel which may imply a risk of payment fraud or other abuses” . (Article 97 of the PSD2)
According to the EBA, “actions carried out via a remote channel that may imply a risk of payment fraud or other abuses could be clarified as covering all actions intrinsically linked to payment services not covered in the categories (a) and (b) above.
This could for example include actions related to :
- the activation and deactivations of payment functionalities,
- the amendment of trusted beneficiaries (“white lists”) – or blocked beneficiaries (“black-lists”),
- the setting of limits or the generation of virtual cards or changing PSU da-ta that may imply a risk of payment fraud or other abuses.
It only includes actions that are conducted via the internet or through a device that can be used for distance communication (e.g. mobile devices).”
However, the risks are not the same if the user only access in read-only mode to its financial data (where the strong customer authentication is not necessary) and if the user access to its banking data with the possibility to conduct financial transactions (external wire transfers for example). In this last hypothesis, strong customer authentication should apply.
Naturally, a mobile phone could be appropriate to be used in the context of strong customer authentication. Therefore, the process would be very simi-lar to the 3D Secure which already exist in order to issue a secured electron-ic signature.
Indeed, a satisfactory authentication system would be based on a SMS au-thentication which is a fluid and enables to authenticate in a strong way the final customer. For example, this system has been implemented by an online bank in France when a new IP address connects to the bank’s web-site. This IP address, once validated by the strong customer authentication, may reconnect just through a login and password.
As a result, the SMS is one of the best way to manage strong customer authentication.
An authentication system which would be too constraining could potential-ly harm the use of AIS. For instance, the calculator system implemented by a financial institution generates a slowdown and a more important con-straint for the users even so the authentication procedure is stronger. The user has to enter its password within the calculator which then provides to him another temporarily password that he must enter within the bank’s website.
This authentication system seems to be too constraining as it requires from the user a physical device by bank that he must all the time possess. For consultation services only, this system is too costly for the user. In respect of this matter, this financial institution turned back and proposed a simple code of access for consultation services.
It would be difficult under French Law as biometric characteristics of the PSU such as a fingerprint or an iris scan are strictly regulated and require a procedure of prior notification before the CNIL. Thus, using inherence may be in certain circumstances more demanding for payment services provider than using other elements.
Thus, the regulatory framework should not be too constraining because it should remain flexible enough to foster the fluidity of the data whilst pre-serving a high-level security framework for the users which they can trust.
The data controller which would then collect biometric data from its users should be subject to specific requirements which would secure the integrity and the confidentiality of the user’s data.
Furthermore, from a technical point of view, the integration of inherence elements within the authentication process seems to be difficult to implement in practice. However, what should be doable would be to use the authentication system already present on IOS or Android smartphones (such as fingerprints) as the authentication process to access to the application of the account information service (AIS) provider.
The strong customer authentication through a token brings some problems as the token is strongly incompatible with the fluidity of the actions that are driven by the user or the account information service. A financial institution in France has imposed the use of those token and received lots of com-plaints from its clients.
By comparison, in Belgium and in Switzerland, strong authentication is most largely accepted as it is universal in all the banks but in France, this procedure stays marginal for the consultation because it generates a more important frustration for the users. We must point out the fact that the users are more reconciled to use strong customer authentication in the framework of a payment or a wire transfer.
Indeed, the use of account information services must enable a wider avail-ability of the data only in consultation. Thus, this financial institution has created codes in read-only mode to offer the consultation to its clients without strong authentication. Thus, a pragmatic approach taking into consideration the real nature of the risks at stake is preferable, especially by distinguishing in accordance with the fact that the access are in read-only mode or not.
-- Strong customer authentication through a mobile
The mobile remains today the only strong authentication element really usable for a fluid and compatible use with the AIS activity. An AIS provider must have the possibility to quickly identity its client, so that this latter is not forced to use a physical token. In the worst case, the AIS provider must do this process only once in order to access in read-only mode to its client’s banking data. The storage of the codes and their transfer must be done through encrypted protocols https in a way that one compromising of the telephone may enable to recover the elements transmitted.
In conclusion, a balance must be found between the raise of the availability of the data for the clients, such as ensuring a high level of security. As a result, the technical solutions that are proposed to the client should meet his expectations to access to his data in a fluid and simplified manner but also to propose a secured context to achieve his actions. Thus, a more constraining legal framework will reduce this fluidity.
A coherence must be found between the authentication conditions imposed to the client on his home banking to access to certain information in read-only mode with the conditions imposed when this same access is done through the AIS provider.
The concept of dynamic linking is also reminded by the article 97 of the PSD, within its 2nd paragraph that provides that “Member States shall ensure that, for electronic remote payment transactions, payment service providers apply strong customer authentication that includes elements which dynamically link the transaction to a specific amount and a specific payee.”
It is necessary that once the strong customer authentication and the recognition of the AIS provider are done, that this latter had an illimited access for the recovery of the data in order to satisfy the customers’ expectations, at least regarding the consultation of those data.
It is also necessary that the dynamic strong customer authentication (SMS Code such as the 3D Secure) could validate a set of operations and not only one. A partner must thus prepare upstream a list of actions to be taken (different payments) and once authenticated in a strong way, the list of actions be directly feasible without new authentication process (such as for example a credit institution who may carry out a set of wire transfers).
In conclusion, a distinction must be done between the consultation of the customer’s data and the execution of payment operations. A dynamic link must be done since the authentication has been authorized.
The validation through SMS fulfils the objective of dynamic linking today. Regarding the independence, it is not so sure as the user can send his au-thentication code via his mobile phone and if this latter is compromised, thus the process of authentication is also compromised as it is this device that will receive the code.
However, this problem does not arise if the user drives the operation through a device (such as a computer) and receives the SMS via his mobile phone, in that case, both the independence and dynamic linking are ful-filled.
As a result, the problem comes from the unicity of the device that send the code only known by the customer and which receives the SMS.
Indeed, the solution via mobile phone brings this problem that if the mobile is compromised, the hacker may potentially intercept the code that was sent to the user through SMS.
However, this problem is common for all the access to the banks’ applica-tions and that it is not possible to impose the physical token to all the banks as this would go against all the usages observed in France and against the needs put forward by the users.
In the end, the 3D Secure authentication through credit card is a reliable and secured system which is compatible with the activity of the AIS provider.
--- Authentication of the AIS provider
Either banks authorize connections using a certificate that has been signed by a licensing authority of AIS providers, or either banks will choose indi-vidually the AIS providers.
Banks must give a token for the AIS provider to enable this latter to recover the data via the API without strong customer authentication during a min-imum of one year.
To our point of view, the authentication process through the service France Connect seems not adequate as if the authentication is made through this process, it must be assigned to all the users an ID France Connect and if a user does not have an ID France Connect, then, he cannot use the AIS.
As a result, the intervention of a third party in the authentication process must remain exceptional.
Finally, the problem with France Connect is that the implementation of this system separates the identity provider from the data provider, namely the ASPSP. Thus, each AIS user should already have a France Connect account to connect which would seriously harm the fluidity in the use of AIS and would risk to harm AIS and PIS. However, the implementation of an Open Connect ID system directly or simply Oauth 2 by the bank or by an AIS for the account of the bank would enable to delete the fact that the AIS or the PIS is able to see the user’s ID.
Thus, the implementation of an Oauth 2 may secure the relationship but in the framework of a disfunctionning of the Oauth 2 system proposed by the bank or, worst, an abusive stop of the authorisation of the AIS by the Bank, the AIS should be able to use by scrapping or by the classic system of customer authentication in order not to cut the flows. This is why the customer or AIS authentication system should be unified.
“(a) the level of risk involved in the service provided ;
(b) the amount, the recurrence of the transaction, or both ;
(c) the payment channel used for the execution of the transaction.”
The note provides that exemptions could apply for :
“A. low-value payments as defined in the PSD2 provided that the risk for cumula-tive transaction are monitored ;
B. outgoing payments to trusted beneficiaries included in previously established white lists by a PSU ;
C. transfers between two accounts of the same PSU held at the same ASPSP ;
D. low-risk transactions based on a transaction risk analysis (taking into account detailed criteria to be defined in the RTS);
E. purely consultative services, with no display of sensitive payment data, taking into account data privacy laws”.
Indeed, it seems that those clarifications are useful as they give concrete examples of exemptions and those latter are constituted by situations in which the risk of fraud is relatively low.
Low payment and consultative services could benefit of the exemption.
Regarding the point E., indeed, it should be clearly distinguished between purely consultative services, for which a strong customer authentication should not be required and services enabling money transfers for which a strong customer authentication is necessary.
Without strong customer authentication, the user should be able to access to the following financial data / functionalities : balance, transactions... Data that are accessible without strong authentication within the bank’s website should not require strong authentication by the AIS provider.
The possibility for the AIS provider to connect on behalf of the customer without strong customer authentication must be maintained.
The read-only mode presents less risks as any transaction can be done without strong customer authentication. As a result, in the event of a data security breach, the AIS provider’s server which stores the passwords could be quickly restrained by changing the passwords in read-only mode or by revoking those latter.
“(1) Customer risk factors:
(a) public companies listed on a stock exchange and subject to disclosure requirements (either by stock exchange rules or through law or enforceable means), which impose requirements to ensure adequate transparency of beneficial ownership;
(b) public administrations or enterprises;
(c) customers that are resident in geographical areas of lower risk as set out in point (3);
[…]
(3) Geographical risk factors:
(a) Member States;
(b) third countries having effective AML/CFT systems;
(c) third countries identified by credible sources as having a low level of corruption or other criminal activity;
(d) third countries which, on the basis of credible sources such as mutual evaluations, detailed assessment reports or published follow-up reports, have requirements to combat money laundering and terrorist financing consistent with the revised FATF Recommendations and effectively implement those requirements.”
Additionnaly, there are also other factors the EBA should take into consideration :
- anti-competition rules : the AIS provider must have a full access to the data that are collected on the bank’s website and no distinction should be made between the rights assigned to credit institutions and AIS and PIS providers.
- enable the AIS provider to be independent of the bank in the connection of the client as long as the AIS provider is known by the bank during the authentication of the client.
- not imposing technical standards to AIS providers which could cut the fluidity of current access (validation through SMS and the trans-formation of current authentication codes in read-only codes could be a track). The SSL certificate to identify the AIS provider is another one.
- The user and the AIS provider must as long as possible use a common authentication system in a way that blocking one way would lead to block the other in order to avoid banks to restrict the fluidity of the actual use.
- The data that are received by the AIS provider must be exactly the same than the one received by the client except if he expressly re-quests otherwise.
- Take into consideration the professional sector (small companies) and the fact that the future RTS will also be applicable for AIS and PIS which use more and more this type of system. AIS’ use in France is significant and must be protected (2 million of customers use AIS today in France and more than 10.000 companies today and in growing of 50% per year).
- It is likely that AIS will disappear if strong customer authentication is required to recover its data or to connect in read-only mode to the banks’ websites because the existence of those services is based on the fluidity of access to the data via a simple and quick authentication. AIS are at the heart of new economic models linked to finance by providing the key data to the Fintech actors after authorization from the client, which would enable to offer to this latter a service (authorization of a loan in one click, financial advice, recommendation of good deals, tax optimization in one click, …) (Ex : Yodlee in the USA). It is thus absolutely necessary that the final user does not need to use AIS or PIS more elements than what he currently holds, namely his banking credentials.
- The legal framework must protect innovative European actors and enable those latter to continue to operate their business such as maintaining security and confidentiality of the client’s data. The stake is huge because it is through those innovative actors that Europe will take part in the worldwide market which is globalizing.
(a) an adequate transaction history of that customer to evaluate the latter’s typical spending and behaviour patterns,
(b) information about the customer device used (e.g. IP address, model, operating system, language preferences) and where applicable,
(c) a detailed risk profile of the payee (e.g. types of service provided, transaction history) and the payees device (where applicable).”
At this stage, we do not see any other criteria or circumstances the EBA should consider apart form the ones listed here above.
Moreover, the recital 96 of the PSD 2 provides that “safe use of personalized security credentials is needed to limit the risks relative to phishing and other fraudulent activities. In that respect, the user should be able to rely on the adoption of measures that protect the confidentiality and integrity of per-sonalised security credentials”.
The note provides examples in which such data is particularly at risk, it is the case where the data is :
“A. created, issued and transmitted to the PSU (commonly referred to as “enrol-ment”), usually when the PSU signs up for a payment services (e.g. the opening of a payment account). Alternatively “enrolment” may be carried out prior to signing up for the payment services or at a later stage by the ASPSP itself (e.g. provision of new or additional types of credentials) or undertaken by providers of electronic identification services (e.g. see below chapter 4.5 on e-IDAS Regulation). In both cases, ASPSPs conduct a customer due diligence, taking into account, amongst others, the identification requirements of the European anti-money laundering legislation prior to registering or acknowledging a personalised security credential and opening an account. In addition, later modifications or re-issuance of the cre-dentials by the PSU need to be protected.
B. stored in a physical device, such as an electronic device (e.g. a mobile device) or a chip on a card, or remotely such as in a hardware security model of server’s data-base. Fraudsters can then attempt to access PSU data by hacking the physical de-vice or the database where the data is stored.
C. transmitted via different communication channels, such as standard telephone line, internet or via radio technologies (e.g. GSM/GPRS/UMTS, Wi-Fi, NFC, and Bluetooth) which are not always especially protected. Fraudsters can then attempt to enter the transmission channel to get access to this data during its transmission.
D. unwittingly supplied by the PSU, as fraudsters may attempt to obtain such data directly from the PSU, for example by social engineering phone calls, sending phishing messages, directing the user to a fraudulent website, or infecting the user PC with malware that for example captures users’ keystrokes during log in and sends the information to the attacker. There are many ways to compromise the PSU’s device with malware, including drive-by downloads, watering hole attacks and infected USB devices.
E. accessed by a third party in the course of a payment service. In such a case, the probability of the risk increases as the attacks described above can be performed also against this third party. In the context of the PIS/AIS services, Art. 66 3(b) and 67 (2) (b) PSD2 require PIS/AIS providers to ensure that the PSCs of the PSU are not accessible to other parties, with the exception of the user and the issuer of the per-sonalized credentials (see further details on this topic in chapter 4.4 below).”
The clarifications suggested are interesting as they identify the problems but however, they do not define technical actions to be taken. As a result, it should be responded to each of them :
• The enrolment seems to be one of the main worries for banks today and the AIS and PIS could rely on the enrol-ment process established by banks. AIS and PIS must simp-ly guarantee that the credentials are well secured during the storage and the transmission process. They are in any case not created by the AIS or the PIS who today simply use the valid e-mail address such as the password.
• It has to be defined minimum security standards to guaran-tee that the login and passwords are stored in a secured manner on servers or within the client’s device.
• The exchanges must in this case be done in HTTPS with the highest level of certification.
• Users must be warned of the risks of phishing and the fraudulent attempts and enable them to identify the trust-worthy players (SPS, AIS and PIS).
We could also quote the risk of identity theft and data security breach. In-deed, the fact that a transaction takes place behind a screen makes the fraud easier, such as, for example, the identify theft.
Furthermore, the authentication of users must be monitored in order to guarantee the security and must enable the bank to know whether it is the AIS or the PIS which is connecting for the client’s account.
Until now, in France, we did not hear about cases which resulted in cyber attacks or data security breach, the actors investing in the securisation of their process.
The actual actors on the market are the following :
- Budget Insight;
- Bankin;
- Linxo;
- Fiduceo.
With the adoption of the PSD 2, all the new actors will be subject to approval (license), which will enable the authorities to validate the securisation of their proposed solutions, the AIS or PIS providers who exercised before the adoption of the PSD 2 being authorized to maintain their activity.
The read-only credentials used by the AIS on behalf of the client for the first connection may be an interesting system which would conserve the fluidity and guarantee after the first connection the security of the client’s data. In all cases with credentials in read-only mode, the risks for the final client are limited once the first connection has been done.
The bank could use the AIS’ SSL certificate to identify this latter and to pro-vide to it a token which would not expire or which expires after a period of 1 year. The notion of token between the bank and the AIS or the PIS for the simple authentication of the client and the access to data in read-only mode is a simple and low-priced way for all the actors. For any financial transac-tion, the strong customer authentication via SMS seems to be a solution which limits ensure fluidity because the client often needs to hold his mo-bile phone on him to finish the strong authentication process.
As a result, the credentials (i) would be in read-only mode and (ii) would not be saved. Thus, the risks of fraud are largely limited.
- Propose the credentials in read-only mode which are powerful in terms of use. Ouath will be costly for everyone.
- The AIS’ license is a true solution and those latter will have to demonstrate that their credentials are encrypted.
- The interactions with banks’ websites must be done through HTTPS protocols with the highest level of certification.
- The achievment of a security audit of the AIS.
- The AIS commits to implement strong security systems of the cre-dentials which are stored with for example encryption through physical devices.
- Use authentication systems such as France Connect appears unsuit-able because it imposes to each user to identity and this is likely to discourage the users to use those services.
- The moment when the client registers its credentials ;
- The moment where his credentials are decrypted in order to be submitted to the authentication on the bank’s website. A hacker who would have entered within the sever could at this moment illicitly recover his credentials. But this risk may be deleted by the use of Oauth 2.
According to Recital 93, these regulatory technical standards shall in par-ticular “ensure that the ASASPSP is aware that he is being contacted by a PIS or an account information service provider and not by the client itself”. They shall also “ensure that PIS and AIS communicate with the account servic-ing payment service provider and with the customers involved in a secure man-ner.” They shall finally “allow for the use of all common types of devices (such as computers, tablets and mobile phones) for carrying out different payment services.”
However, PSD2 does not mandate EBA to develop or maintain these open and common standards of communication themselves or to ap-point a central entity in charge of developing or maintaining these standards. Moreover, the requirements set by the EBA “should ensure the interoperability of different technological communication solutions.” (Recital 93).
“A potentially helpful way to address this issue would be for the EBA to consider clarification in its future regulatory technical standards on the following aspects:
a. Define what makes a standard “common” and “open”
b. The way AIS, PIS providers will have to identify themselves towards the ASASPSPs for access to payment account information (e.g. exchange of elec-tronic certificates, see as well chapter 4.5), and every time a payment is initiat-ed including the purpose for which the AIS and/or PIS is authorised by the PSU and requesting access to the ASASPSP upon each connection. Such requirements could clarify whether or not trusted third-parties need to provide assurance (e.g. in the form of security assertions) about the identification of entities involved in such communication,
c. The way PIS, AIS and ASASPSPs communicate between themselves and with the PSUs in a secure manner,
d. The minimum functionalities requirements that the future common and secure open standards of communication will have to provide. This includes for example what kind of information/services can be requested via the standard of communication (e.g. information on the availability of funds or initiation of a payment), how the identification of the account to be accessed and consent of the PSU should be conveyed,
e. The minimum security controls that the future common and secure open stand-ards of communication will have to provide related to the potential unauthorised or fraudulent access to payment accounts or initiation of a payment transaction,
f. the minimum technical requirements that could apply to the common and secure open standards of communication, the minimum reachability requirements for each ASASPSPs to provide at least one interoperable interface serving all require-ments of the RTS and compliant with PSD2 regulation, while AIS and PIS would have to adapt their services to the respective standardised interfaces used.”
You will find hereunder some clarifications regarding the different points (a to f) that are described within the note :
a. A common and secured open standard of communication would be an open source authentication technology shared between the banks the AIS and PIS. The problem with this definition is that banks will not be prone to use open source technologies to authen-tify their clients but will aim to perfectly monitor their systems, which is a legitimate expectation as it concerns their clients and their relationship with those latter such as the security of the data apportioned. Currently, Budget Insight already uses an open and secured open standard of communication named WEBOOB. It is an Open Source bookcase which enables to simulate a connection to banks’ website without using a web browser. It is in fact a kind of multifaceted API which is adapted to the banks’ website to read the information that are presented once the connection has been done. A work on WEBOOB could lead to create an efficient link be-tween banks and AIS and PIS and thus, WEBOOB could become a standard authentication and exchange of banking data process under the condition to make it evolved to Oauth2 authentication systems.
b. The way for the AIS and the PIS to identify themselves from the ASPSC may depend from the bank. The key element is the accredit-ed AIS and PIS’ directory which must remain accessible at any time by the bank to confront the token or the AIS or PIS certificate to the directory’s databases. The SSL certificate seems to be once again a good track to authentify in a simple way the AIS or the PIS because all the relevant actors from the market currently use a SSL certificate with the highest level of certification which requires a strong au-thentication of the AIS or PIS from the certificate’s issuer. In this way, the EBA could, through the SSL protocol, for the accreditation of AIS vis-à-vis banks, could become the equivalent of Geotrust or Verisign vis-à-vis web browsers.
c. The exchange protocols between actors must be encrypted in order to avoid hackers to access to the shared data. The obligation to use HTTPS exchange protocols is required from the AIS at any time when they transit data through the internet. It is today the case for the historical actors.
d. The common and secured open standard of communication must offer an exhaustive model of data and which enable AIS to access exactly to the same data that the user on his bank’s website. Indeed, we have to keep in mind that the AIS and PIS’ job is to connect to the bank’s website as the user would do to simplify its path and thus, remove those data from the AIS or PIS would result in the de-struction of the reason why those actors exist.
e. The communication standards (as it is likely that there will be sev-eral) will have to put in place control systems of fraudulent access. It is a key element which will enable the AIS, PIS and ASPSP to guarantee the security of the system.
f. The ASPSP will only need to provide the following services in order to be compliant with the PSD 2 to answer to the user’s expectations :
o Provide a service enabling the AIS or the PIS to authentify itself from the service during the authentication of the client (for example via s SSL protocol);
o Provide an authentication system by SMS to the first au-thentication of a new IP address of the first time that an AIS or PIS authentifies itself for the client (similar system to the 3D Secure);
o OPTIONALLY : the ASPSP would be equipped of an au-thentication system like Open source Oauth Open ID Con-nect kind to enable the AIS or PIS to authenticate itself and the client.
o OPTIONALLY : the ASPSP may create an API according to classical data model from the market (for example WE-BOOB) to which the AIS or PIS could connect to recover the data, the API could also may be used within the website or the mobile application.
It has to be noted that at this stage Budget Insight proposes its services to ASPSP in order to accompany them in the transformations linked to the PSD 2 to enable those latter to implement secured and efficient exchange systems with the AIS and PIS.
- Users should not need to use more elements to connect their ac-counts via an AIS or PIS than their banking credentials and a SMS validation or a code received on their mobile phone (physical to-kens seriously harm the fluidity);
- Once the connection with an AIS or PIS done, this connection should be persistant and should not require a new strong authenti-cation to each refreshment.
- The authentication path for AIS or PIS must the same than the one which is used by the user in a way that cutting one would result to cut the other, which will result in the fact that the bank could not avoid an AIS or PIS to connect unless this latter had been removed from the licensed AIS/PIS’ directory.
- The data to which AIS and PIS have access must be strictly the same than the ones to which the final client has his access.
Furthermore, the following elements should be taken into consideration :
- It should not be imposed to ASPS a particular technology nor a par-ticular way of functioning but it should be required from them some practices listed here above in order to let them some freedrom regarding their information system ;
- Existing systems should be used and which do not require a heavy implementation for ASPSP :
o SSL Protocol to identify AIS or PIS ;
o Keep the actual credentials ot ensure the connection;
o Use the SMS for strong authentication which is a system which ensure fluidity;
- The creation of API with a model of data type WEBOOB;
- The use of an Connect Open ID system could be implemented by the AIS or even provided by the AIS and could also be used for the authentication of the client ;
- Working with an AIS or PIS on the creation of their authentication systems or their APIs.
- For the strong customer authentication : we can quote the 3D Secure ;
- For secure and open standards of communications : in France, there is France connect and the open ID system to manage the authentica-tion.
But any of the actual solutions which constitute a simple way of au-thentication enable a full access to the data such as scrapping. In-deed, the Open Bank API or Castore solutions provide a data which is incomplete compare to WEBOOB or to the model of dada of AIS such as Budget Insight, the most important element being that the AIS must have the same access and the same quality of information to the data than the client when this latter accesses to his home banking in read-only mode.
Thus, AIS are already authentication API for the account of others Fintechs and by this way are at the heart of exchange and securing systems of bank-ing data for the account of innovative actors.
For a performing system, this latter must be based on existing and ap-proved technologies in order to guarantee the adequate security level and the fluidity of the system (conservation for the authentication of historical credentials, use of SMS on the customer’s mobile phone for the strong au-thentication, use of SSL protocols).
The notion of API and data recovery for the account of the client through a service platform is already a usage developed by AIS such as Budget In-sight through his API Budgea. The key of this model does not necessarily consist in a structured API which will be costly and impossible to integrate for all the banks but through authentication systems which ease and secure the communications between ASPSP, AIS and PIS.
The notion of open source is not necessarily mandatory, ASPSP should be able to choose. Having said that, it must be mandatory for the ASPSP that whatever the technology chosen, this latter complies with strong commit-ments provided by the PSD 2 and enable to all licensed AIS or PIS to con-nect on behalf of the client through an authentication path identical to the one the client would use in order to connect alone.
- “a. lays down the conditions under which Member States recognise electronic identification means of natural and legal persons falling under a notified electronic identification scheme of another Member State;
- b. sets out a supervisory and liability regime to enable qualified trust services providers to deliver, at domestic and cross-border level, qualified trust services with a high level of assurance for electronic transactions;
- c. establishes a legal framework for electronic signatures, electronic seals, electronic time stamps, electronic documents, electronic registered de-livery services and certificate services for website authentication; and
- d. is mandatory for cross-border access to public services in EU countries where eIDs are available. Yes, e-IDAS regulation could be considered as a possible solution for facilitating the strong customer authentication. “
Indeed, the notion of qualified trust services and trust service provider goes with the application of certain requirements and obligations that ensure high-level security of whatever qualified trust services and products are used or provided (not for all issues, but could be useful for the identifica-tion of the AIS, PIS providers towards the ASASPSPs for access to payment account information (exchange of electronic certificates)) :
- qualified electronic signature and licensed provider ;
- asymetric encryption ;
- authentication from the bank.
The e-IDAS regulation could be used but under the condition that it does not require strong customer authentication for any connection enaling to an AIS a refreshment of the data. E-IDAS aims to propose interoperability, which is a good thing and which ease the authentication of the user and guarantees the safety of data.
To develop the current models and to develop future models around bank-ing data, the fluidity and the rapidity of access to the data that historical AIS and PIS have implemented must be maintained.
The requirements applicable to qualified trust services are detailed within the section 3 (“Qualified Trust Services”) of Chapter III (“Trust Services”).
More specifically, the article 24 (2) (“Requirements for qualified trust service providers”) provides that :
“2. A qualified trust service provider providing qualified trust services shall:
(a) inform the supervisory body of any change in the provision of its qualified trust services and an intention to cease those activities;
(b) employ staff and, if applicable, subcontractors who possess the necessary exper-tise, reliability, experience, and qualifications and who have received appropriate training regarding security and personal data protection rules and shall apply administrative and management procedures which correspond to European or in-ternational standards;
(c) with regard to the risk of liability for damages in accordance with Article 13, maintain sufficient financial resources and/or obtain appropriate liability insur-ance, in accordance with national law;
(d) before entering into a contractual relationship, inform, in a clear and compre-hensive manner, any person seeking to use a qualified trust service of the precise terms and conditions regarding the use of that service, including any limitations on its use;
(e) use trustworthy systems and products that are protected against modification and ensure the technical security and reliability of the processes supported by them;
(f) use trustworthy systems to store data provided to it, in a verifiable form so that:
(i) they are publicly available for retrieval only where the consent of the person to whom the data relates has been obtained,
(ii) only authorised persons can make entries and changes to the stored da-ta, (iii) the data can be checked for authenticity;
(g) take appropriate measures against forgery and theft of data;
(h) record and keep accessible for an appropriate period of time, including after the activities of the qualified trust service provider have ceased, all relevant information concerning data issued and received by the qualified trust service provider, in par-ticular, for the purpose of providing evidence in legal proceedings and for the pur-pose of ensuring continuity of the service. Such recording may be done electroni-cally;
(i) have an up-to-date termination plan to ensure continuity of service in accord-ance with provisions verified by the supervisory body under point (i) of Article 17(4);
(j) ensure lawful processing of personal data in accordance with Directive 95/46/EC;
(k) in case of qualified trust service providers issuing qualified certificates, establish and keep updated a certificate database.”
The use of “qualified trust services” under e-IDAS regulation could address the risks related to the confidentiality, integrity and availability of PSCs between AIS, PIS providers and ASASPSPs for payment services, provided that the fluidity and the rapidity of access to the data that historical AIS and PIS have implemented must be maintained.
1. With respect to Article 97(1) (c), are there any additional examples of transactions or actions implying a risk of payment fraud or other abuses that would need to be considered for the RTS? If so, please give details and explain the risks involved.
In the framework of AIS, requiring the strong customer authentication to each connection will result in the end of the use of AIS. The risks of abuses exist and are linked to phishing which may be mitigated by the strong authentication procedure. If the codes accessible without strong customer authentication are in read-only mode, the phishing is limited to the access to those data which represent a risk on the confidentiality of the data but not in terms of financial damages for the user.It has to be noted that to develop the use of AIS, it is necessary that AIS and PIS providers have access to the set of data to which the user has access to via his banking connection. The object of the future RTS will then be to en-sure to AIS and PIS the access to those data by protecting the final user from the phishing or other fraudulent practices.
Furthermore, the term of “other abuses” seems to be particularly wide and should be clarified as to which kind of abuses the articles relates to.
Indeed, “Member States shall ensure that a payment service provider applies strong customer authentication where the payer :
(a) accesses its payment account online ;
(b) initiates an electronic payment transaction ;
(c) carries out any action through a remote channel which may imply a risk of payment fraud or other abuses” . (Article 97 of the PSD2)
According to the EBA, “actions carried out via a remote channel that may imply a risk of payment fraud or other abuses could be clarified as covering all actions intrinsically linked to payment services not covered in the categories (a) and (b) above.
This could for example include actions related to :
- the activation and deactivations of payment functionalities,
- the amendment of trusted beneficiaries (“white lists”) – or blocked beneficiaries (“black-lists”),
- the setting of limits or the generation of virtual cards or changing PSU da-ta that may imply a risk of payment fraud or other abuses.
It only includes actions that are conducted via the internet or through a device that can be used for distance communication (e.g. mobile devices).”
However, the risks are not the same if the user only access in read-only mode to its financial data (where the strong customer authentication is not necessary) and if the user access to its banking data with the possibility to conduct financial transactions (external wire transfers for example). In this last hypothesis, strong customer authentication should apply.
2. Which examples of possession elements do you consider as appropriate to be used in the context of strong customer authentication, must these have a physical form or can they be data? If so, can you provide details on how it can be ensured that these data can only be controlled by the PSU?
The discussion paper already gives several examples related to the posses-sion elements. Indeed, according to the text, “these could be described as cover-ing the possession of a physical object or potentially data controlled only by the payment service user”.Naturally, a mobile phone could be appropriate to be used in the context of strong customer authentication. Therefore, the process would be very simi-lar to the 3D Secure which already exist in order to issue a secured electron-ic signature.
Indeed, a satisfactory authentication system would be based on a SMS au-thentication which is a fluid and enables to authenticate in a strong way the final customer. For example, this system has been implemented by an online bank in France when a new IP address connects to the bank’s web-site. This IP address, once validated by the strong customer authentication, may reconnect just through a login and password.
As a result, the SMS is one of the best way to manage strong customer authentication.
An authentication system which would be too constraining could potential-ly harm the use of AIS. For instance, the calculator system implemented by a financial institution generates a slowdown and a more important con-straint for the users even so the authentication procedure is stronger. The user has to enter its password within the calculator which then provides to him another temporarily password that he must enter within the bank’s website.
This authentication system seems to be too constraining as it requires from the user a physical device by bank that he must all the time possess. For consultation services only, this system is too costly for the user. In respect of this matter, this financial institution turned back and proposed a simple code of access for consultation services.
3. Do you consider that in the context of “inherence” elements, behaviour-based characteristics are appropriate to be used in the context of strong customer authentication? If so, can you specify under which conditions?
“Inherence” is defined as something the user is. Once again, the Discussion paper specified the “inherence” element by providing that “these could be clarified as covering biometric characteristics of the PSU such as a fingerprint or an iris scan”.It would be difficult under French Law as biometric characteristics of the PSU such as a fingerprint or an iris scan are strictly regulated and require a procedure of prior notification before the CNIL. Thus, using inherence may be in certain circumstances more demanding for payment services provider than using other elements.
Thus, the regulatory framework should not be too constraining because it should remain flexible enough to foster the fluidity of the data whilst pre-serving a high-level security framework for the users which they can trust.
The data controller which would then collect biometric data from its users should be subject to specific requirements which would secure the integrity and the confidentiality of the user’s data.
Furthermore, from a technical point of view, the integration of inherence elements within the authentication process seems to be difficult to implement in practice. However, what should be doable would be to use the authentication system already present on IOS or Android smartphones (such as fingerprints) as the authentication process to access to the application of the account information service (AIS) provider.
4. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to the independence of the authentication elements used (e.g. for mobile devices)?
-- Strong customer authentication through a tokenThe strong customer authentication through a token brings some problems as the token is strongly incompatible with the fluidity of the actions that are driven by the user or the account information service. A financial institution in France has imposed the use of those token and received lots of com-plaints from its clients.
By comparison, in Belgium and in Switzerland, strong authentication is most largely accepted as it is universal in all the banks but in France, this procedure stays marginal for the consultation because it generates a more important frustration for the users. We must point out the fact that the users are more reconciled to use strong customer authentication in the framework of a payment or a wire transfer.
Indeed, the use of account information services must enable a wider avail-ability of the data only in consultation. Thus, this financial institution has created codes in read-only mode to offer the consultation to its clients without strong authentication. Thus, a pragmatic approach taking into consideration the real nature of the risks at stake is preferable, especially by distinguishing in accordance with the fact that the access are in read-only mode or not.
-- Strong customer authentication through a mobile
The mobile remains today the only strong authentication element really usable for a fluid and compatible use with the AIS activity. An AIS provider must have the possibility to quickly identity its client, so that this latter is not forced to use a physical token. In the worst case, the AIS provider must do this process only once in order to access in read-only mode to its client’s banking data. The storage of the codes and their transfer must be done through encrypted protocols https in a way that one compromising of the telephone may enable to recover the elements transmitted.
In conclusion, a balance must be found between the raise of the availability of the data for the clients, such as ensuring a high level of security. As a result, the technical solutions that are proposed to the client should meet his expectations to access to his data in a fluid and simplified manner but also to propose a secured context to achieve his actions. Thus, a more constraining legal framework will reduce this fluidity.
A coherence must be found between the authentication conditions imposed to the client on his home banking to access to certain information in read-only mode with the conditions imposed when this same access is done through the AIS provider.
5. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to dynamic linking?
The recital 95 of the PSD2 reminds that the security of payment services is essential to limit the risk of fraud, and thus technologies used must be able to guarantee the safe authentication of the user. Besides, “payment services offered via internet or via other at-distance channels, the functioning of which does not depend on where the device used to initiate the payment transaction or the payment instrument used are physically located, should therefore include the authentication of transactions through dynamic codes, in order to make the user aware, at all times, of the amount and the payee of the transaction that the user is authorising.”The concept of dynamic linking is also reminded by the article 97 of the PSD, within its 2nd paragraph that provides that “Member States shall ensure that, for electronic remote payment transactions, payment service providers apply strong customer authentication that includes elements which dynamically link the transaction to a specific amount and a specific payee.”
It is necessary that once the strong customer authentication and the recognition of the AIS provider are done, that this latter had an illimited access for the recovery of the data in order to satisfy the customers’ expectations, at least regarding the consultation of those data.
It is also necessary that the dynamic strong customer authentication (SMS Code such as the 3D Secure) could validate a set of operations and not only one. A partner must thus prepare upstream a list of actions to be taken (different payments) and once authenticated in a strong way, the list of actions be directly feasible without new authentication process (such as for example a credit institution who may carry out a set of wire transfers).
In conclusion, a distinction must be done between the consultation of the customer’s data and the execution of payment operations. A dynamic link must be done since the authentication has been authorized.
6. In your view, which solutions for mobile devices fulfil both the objective of independence and dynamic linking already today?
---- Authentication of the customerThe validation through SMS fulfils the objective of dynamic linking today. Regarding the independence, it is not so sure as the user can send his au-thentication code via his mobile phone and if this latter is compromised, thus the process of authentication is also compromised as it is this device that will receive the code.
However, this problem does not arise if the user drives the operation through a device (such as a computer) and receives the SMS via his mobile phone, in that case, both the independence and dynamic linking are ful-filled.
As a result, the problem comes from the unicity of the device that send the code only known by the customer and which receives the SMS.
Indeed, the solution via mobile phone brings this problem that if the mobile is compromised, the hacker may potentially intercept the code that was sent to the user through SMS.
However, this problem is common for all the access to the banks’ applica-tions and that it is not possible to impose the physical token to all the banks as this would go against all the usages observed in France and against the needs put forward by the users.
In the end, the 3D Secure authentication through credit card is a reliable and secured system which is compatible with the activity of the AIS provider.
--- Authentication of the AIS provider
Either banks authorize connections using a certificate that has been signed by a licensing authority of AIS providers, or either banks will choose indi-vidually the AIS providers.
Banks must give a token for the AIS provider to enable this latter to recover the data via the API without strong customer authentication during a min-imum of one year.
To our point of view, the authentication process through the service France Connect seems not adequate as if the authentication is made through this process, it must be assigned to all the users an ID France Connect and if a user does not have an ID France Connect, then, he cannot use the AIS.
As a result, the intervention of a third party in the authentication process must remain exceptional.
Finally, the problem with France Connect is that the implementation of this system separates the identity provider from the data provider, namely the ASPSP. Thus, each AIS user should already have a France Connect account to connect which would seriously harm the fluidity in the use of AIS and would risk to harm AIS and PIS. However, the implementation of an Open Connect ID system directly or simply Oauth 2 by the bank or by an AIS for the account of the bank would enable to delete the fact that the AIS or the PIS is able to see the user’s ID.
Thus, the implementation of an Oauth 2 may secure the relationship but in the framework of a disfunctionning of the Oauth 2 system proposed by the bank or, worst, an abusive stop of the authorisation of the AIS by the Bank, the AIS should be able to use by scrapping or by the classic system of customer authentication in order not to cut the flows. This is why the customer or AIS authentication system should be unified.
7. Do you consider the clarifications suggested regarding the potential exemptions to strong customer authentication, to be useful?
The Article 98 of the PSD 2 provides that the exemptions must be based on the following criteria :“(a) the level of risk involved in the service provided ;
(b) the amount, the recurrence of the transaction, or both ;
(c) the payment channel used for the execution of the transaction.”
The note provides that exemptions could apply for :
“A. low-value payments as defined in the PSD2 provided that the risk for cumula-tive transaction are monitored ;
B. outgoing payments to trusted beneficiaries included in previously established white lists by a PSU ;
C. transfers between two accounts of the same PSU held at the same ASPSP ;
D. low-risk transactions based on a transaction risk analysis (taking into account detailed criteria to be defined in the RTS);
E. purely consultative services, with no display of sensitive payment data, taking into account data privacy laws”.
Indeed, it seems that those clarifications are useful as they give concrete examples of exemptions and those latter are constituted by situations in which the risk of fraud is relatively low.
Low payment and consultative services could benefit of the exemption.
Regarding the point E., indeed, it should be clearly distinguished between purely consultative services, for which a strong customer authentication should not be required and services enabling money transfers for which a strong customer authentication is necessary.
Without strong customer authentication, the user should be able to access to the following financial data / functionalities : balance, transactions... Data that are accessible without strong authentication within the bank’s website should not require strong authentication by the AIS provider.
The possibility for the AIS provider to connect on behalf of the customer without strong customer authentication must be maintained.
The read-only mode presents less risks as any transaction can be done without strong customer authentication. As a result, in the event of a data security breach, the AIS provider’s server which stores the passwords could be quickly restrained by changing the passwords in read-only mode or by revoking those latter.
8. Are there any other factors the EBA should consider when deciding on the exemptions applicable to the forthcoming regulatory technical standards?
We could for example, in order to align those RTS with the current Europe-an legislation, refer to the Annex II of the Directive EU 2015/849 of 20 May 2015 on the prevention of money laundering and terrorist financing and the list of factors and types of evidence of potentially lower risks :“(1) Customer risk factors:
(a) public companies listed on a stock exchange and subject to disclosure requirements (either by stock exchange rules or through law or enforceable means), which impose requirements to ensure adequate transparency of beneficial ownership;
(b) public administrations or enterprises;
(c) customers that are resident in geographical areas of lower risk as set out in point (3);
[…]
(3) Geographical risk factors:
(a) Member States;
(b) third countries having effective AML/CFT systems;
(c) third countries identified by credible sources as having a low level of corruption or other criminal activity;
(d) third countries which, on the basis of credible sources such as mutual evaluations, detailed assessment reports or published follow-up reports, have requirements to combat money laundering and terrorist financing consistent with the revised FATF Recommendations and effectively implement those requirements.”
Additionnaly, there are also other factors the EBA should take into consideration :
- anti-competition rules : the AIS provider must have a full access to the data that are collected on the bank’s website and no distinction should be made between the rights assigned to credit institutions and AIS and PIS providers.
- enable the AIS provider to be independent of the bank in the connection of the client as long as the AIS provider is known by the bank during the authentication of the client.
- not imposing technical standards to AIS providers which could cut the fluidity of current access (validation through SMS and the trans-formation of current authentication codes in read-only codes could be a track). The SSL certificate to identify the AIS provider is another one.
- The user and the AIS provider must as long as possible use a common authentication system in a way that blocking one way would lead to block the other in order to avoid banks to restrict the fluidity of the actual use.
- The data that are received by the AIS provider must be exactly the same than the one received by the client except if he expressly re-quests otherwise.
- Take into consideration the professional sector (small companies) and the fact that the future RTS will also be applicable for AIS and PIS which use more and more this type of system. AIS’ use in France is significant and must be protected (2 million of customers use AIS today in France and more than 10.000 companies today and in growing of 50% per year).
- It is likely that AIS will disappear if strong customer authentication is required to recover its data or to connect in read-only mode to the banks’ websites because the existence of those services is based on the fluidity of access to the data via a simple and quick authentication. AIS are at the heart of new economic models linked to finance by providing the key data to the Fintech actors after authorization from the client, which would enable to offer to this latter a service (authorization of a loan in one click, financial advice, recommendation of good deals, tax optimization in one click, …) (Ex : Yodlee in the USA). It is thus absolutely necessary that the final user does not need to use AIS or PIS more elements than what he currently holds, namely his banking credentials.
- The legal framework must protect innovative European actors and enable those latter to continue to operate their business such as maintaining security and confidentiality of the client’s data. The stake is huge because it is through those innovative actors that Europe will take part in the worldwide market which is globalizing.
9. Are there any other criteria or circumstances which the EBA should consider with respect to transaction risks analysis as a complement or alternative to the criteria identified in paragraph 45?
According to the article 45 of the Discussion Paper, the EBA should clarify in its future regulatory technical standards as to which kind of capabilities and minimum set of information are required for such tools reliably to evaluate the risk of a transaction. “Such capability could, for example, be re-quired to be based on comprehensive real-time risk analysis taking into account :(a) an adequate transaction history of that customer to evaluate the latter’s typical spending and behaviour patterns,
(b) information about the customer device used (e.g. IP address, model, operating system, language preferences) and where applicable,
(c) a detailed risk profile of the payee (e.g. types of service provided, transaction history) and the payees device (where applicable).”
At this stage, we do not see any other criteria or circumstances the EBA should consider apart form the ones listed here above.
10. Do you consider the clarification suggested regarding the protection of users personalised security credentials to be useful?
Article 4 (31) defines “personalized security credentials” as personalised fea-tures provided by the ASPSPs to a PSU for the purpose of authentication.Moreover, the recital 96 of the PSD 2 provides that “safe use of personalized security credentials is needed to limit the risks relative to phishing and other fraudulent activities. In that respect, the user should be able to rely on the adoption of measures that protect the confidentiality and integrity of per-sonalised security credentials”.
The note provides examples in which such data is particularly at risk, it is the case where the data is :
“A. created, issued and transmitted to the PSU (commonly referred to as “enrol-ment”), usually when the PSU signs up for a payment services (e.g. the opening of a payment account). Alternatively “enrolment” may be carried out prior to signing up for the payment services or at a later stage by the ASPSP itself (e.g. provision of new or additional types of credentials) or undertaken by providers of electronic identification services (e.g. see below chapter 4.5 on e-IDAS Regulation). In both cases, ASPSPs conduct a customer due diligence, taking into account, amongst others, the identification requirements of the European anti-money laundering legislation prior to registering or acknowledging a personalised security credential and opening an account. In addition, later modifications or re-issuance of the cre-dentials by the PSU need to be protected.
B. stored in a physical device, such as an electronic device (e.g. a mobile device) or a chip on a card, or remotely such as in a hardware security model of server’s data-base. Fraudsters can then attempt to access PSU data by hacking the physical de-vice or the database where the data is stored.
C. transmitted via different communication channels, such as standard telephone line, internet or via radio technologies (e.g. GSM/GPRS/UMTS, Wi-Fi, NFC, and Bluetooth) which are not always especially protected. Fraudsters can then attempt to enter the transmission channel to get access to this data during its transmission.
D. unwittingly supplied by the PSU, as fraudsters may attempt to obtain such data directly from the PSU, for example by social engineering phone calls, sending phishing messages, directing the user to a fraudulent website, or infecting the user PC with malware that for example captures users’ keystrokes during log in and sends the information to the attacker. There are many ways to compromise the PSU’s device with malware, including drive-by downloads, watering hole attacks and infected USB devices.
E. accessed by a third party in the course of a payment service. In such a case, the probability of the risk increases as the attacks described above can be performed also against this third party. In the context of the PIS/AIS services, Art. 66 3(b) and 67 (2) (b) PSD2 require PIS/AIS providers to ensure that the PSCs of the PSU are not accessible to other parties, with the exception of the user and the issuer of the per-sonalized credentials (see further details on this topic in chapter 4.4 below).”
The clarifications suggested are interesting as they identify the problems but however, they do not define technical actions to be taken. As a result, it should be responded to each of them :
• The enrolment seems to be one of the main worries for banks today and the AIS and PIS could rely on the enrol-ment process established by banks. AIS and PIS must simp-ly guarantee that the credentials are well secured during the storage and the transmission process. They are in any case not created by the AIS or the PIS who today simply use the valid e-mail address such as the password.
• It has to be defined minimum security standards to guaran-tee that the login and passwords are stored in a secured manner on servers or within the client’s device.
• The exchanges must in this case be done in HTTPS with the highest level of certification.
• Users must be warned of the risks of phishing and the fraudulent attempts and enable them to identify the trust-worthy players (SPS, AIS and PIS).
11. What other risks with regard to the protection of users’ personalised security credentials do you identify?
The risks already identified are related to phishing and other fraudulent activities.We could also quote the risk of identity theft and data security breach. In-deed, the fact that a transaction takes place behind a screen makes the fraud easier, such as, for example, the identify theft.
Furthermore, the authentication of users must be monitored in order to guarantee the security and must enable the bank to know whether it is the AIS or the PIS which is connecting for the client’s account.
Until now, in France, we did not hear about cases which resulted in cyber attacks or data security breach, the actors investing in the securisation of their process.
The actual actors on the market are the following :
- Budget Insight;
- Bankin;
- Linxo;
- Fiduceo.
With the adoption of the PSD 2, all the new actors will be subject to approval (license), which will enable the authorities to validate the securisation of their proposed solutions, the AIS or PIS providers who exercised before the adoption of the PSD 2 being authorized to maintain their activity.
12. Have you identified innovative solutions for the enrolment process that the EBA should consider which guarantee the confidentiality, integrity and secure transmission (e.g. physical or electronic delivery) of the users’ personalised security credentials?
There are some innovative solutions for the enrolment process such as voice over IP or Interactive voice response systems or electronic registered letter with an acknowledgment of receipt.The read-only credentials used by the AIS on behalf of the client for the first connection may be an interesting system which would conserve the fluidity and guarantee after the first connection the security of the client’s data. In all cases with credentials in read-only mode, the risks for the final client are limited once the first connection has been done.
The bank could use the AIS’ SSL certificate to identify this latter and to pro-vide to it a token which would not expire or which expires after a period of 1 year. The notion of token between the bank and the AIS or the PIS for the simple authentication of the client and the access to data in read-only mode is a simple and low-priced way for all the actors. For any financial transac-tion, the strong customer authentication via SMS seems to be a solution which limits ensure fluidity because the client often needs to hold his mo-bile phone on him to finish the strong authentication process.
As a result, the credentials (i) would be in read-only mode and (ii) would not be saved. Thus, the risks of fraud are largely limited.
13. Can you identify alternatives to certification or evaluation by third parties of technical components or devices hosting payment solutions, to ensure that communication channels and technical components hosting, providing access to or transmitting the personalised security credential are sufficiently resistant to tampering and unauthorized access?
Indeed, we can quote the following alternatives :- Propose the credentials in read-only mode which are powerful in terms of use. Ouath will be costly for everyone.
- The AIS’ license is a true solution and those latter will have to demonstrate that their credentials are encrypted.
- The interactions with banks’ websites must be done through HTTPS protocols with the highest level of certification.
- The achievment of a security audit of the AIS.
- The AIS commits to implement strong security systems of the cre-dentials which are stored with for example encryption through physical devices.
- Use authentication systems such as France Connect appears unsuit-able because it imposes to each user to identity and this is likely to discourage the users to use those services.
14. Can you indicate the segment of the payment chain in which risks to the confidentiality, integrity of users’ personalised security credentials are most likely to occur at present and in the foreseeable future?
The two segments of the payment chain in which risks to the confidentiality, integrity of user’ personalised security credentials are most likely to occur at present and in the foreseeable future are the following :- The moment when the client registers its credentials ;
- The moment where his credentials are decrypted in order to be submitted to the authentication on the bank’s website. A hacker who would have entered within the sever could at this moment illicitly recover his credentials. But this risk may be deleted by the use of Oauth 2.
15. For each of the topics identified under paragraph 63 above (a to f), do you consider the clarifications provided to be comprehensive and suitable? If not, why not?
AIS and PIS providers are required to act only upon the explicit consent of the PSU . (Article 65-67). The way how consent is given will be agreed be-tween the payer and the relevant provider (Article 64).According to Recital 93, these regulatory technical standards shall in par-ticular “ensure that the ASASPSP is aware that he is being contacted by a PIS or an account information service provider and not by the client itself”. They shall also “ensure that PIS and AIS communicate with the account servic-ing payment service provider and with the customers involved in a secure man-ner.” They shall finally “allow for the use of all common types of devices (such as computers, tablets and mobile phones) for carrying out different payment services.”
However, PSD2 does not mandate EBA to develop or maintain these open and common standards of communication themselves or to ap-point a central entity in charge of developing or maintaining these standards. Moreover, the requirements set by the EBA “should ensure the interoperability of different technological communication solutions.” (Recital 93).
“A potentially helpful way to address this issue would be for the EBA to consider clarification in its future regulatory technical standards on the following aspects:
a. Define what makes a standard “common” and “open”
b. The way AIS, PIS providers will have to identify themselves towards the ASASPSPs for access to payment account information (e.g. exchange of elec-tronic certificates, see as well chapter 4.5), and every time a payment is initiat-ed including the purpose for which the AIS and/or PIS is authorised by the PSU and requesting access to the ASASPSP upon each connection. Such requirements could clarify whether or not trusted third-parties need to provide assurance (e.g. in the form of security assertions) about the identification of entities involved in such communication,
c. The way PIS, AIS and ASASPSPs communicate between themselves and with the PSUs in a secure manner,
d. The minimum functionalities requirements that the future common and secure open standards of communication will have to provide. This includes for example what kind of information/services can be requested via the standard of communication (e.g. information on the availability of funds or initiation of a payment), how the identification of the account to be accessed and consent of the PSU should be conveyed,
e. The minimum security controls that the future common and secure open stand-ards of communication will have to provide related to the potential unauthorised or fraudulent access to payment accounts or initiation of a payment transaction,
f. the minimum technical requirements that could apply to the common and secure open standards of communication, the minimum reachability requirements for each ASASPSPs to provide at least one interoperable interface serving all require-ments of the RTS and compliant with PSD2 regulation, while AIS and PIS would have to adapt their services to the respective standardised interfaces used.”
You will find hereunder some clarifications regarding the different points (a to f) that are described within the note :
a. A common and secured open standard of communication would be an open source authentication technology shared between the banks the AIS and PIS. The problem with this definition is that banks will not be prone to use open source technologies to authen-tify their clients but will aim to perfectly monitor their systems, which is a legitimate expectation as it concerns their clients and their relationship with those latter such as the security of the data apportioned. Currently, Budget Insight already uses an open and secured open standard of communication named WEBOOB. It is an Open Source bookcase which enables to simulate a connection to banks’ website without using a web browser. It is in fact a kind of multifaceted API which is adapted to the banks’ website to read the information that are presented once the connection has been done. A work on WEBOOB could lead to create an efficient link be-tween banks and AIS and PIS and thus, WEBOOB could become a standard authentication and exchange of banking data process under the condition to make it evolved to Oauth2 authentication systems.
b. The way for the AIS and the PIS to identify themselves from the ASPSC may depend from the bank. The key element is the accredit-ed AIS and PIS’ directory which must remain accessible at any time by the bank to confront the token or the AIS or PIS certificate to the directory’s databases. The SSL certificate seems to be once again a good track to authentify in a simple way the AIS or the PIS because all the relevant actors from the market currently use a SSL certificate with the highest level of certification which requires a strong au-thentication of the AIS or PIS from the certificate’s issuer. In this way, the EBA could, through the SSL protocol, for the accreditation of AIS vis-à-vis banks, could become the equivalent of Geotrust or Verisign vis-à-vis web browsers.
c. The exchange protocols between actors must be encrypted in order to avoid hackers to access to the shared data. The obligation to use HTTPS exchange protocols is required from the AIS at any time when they transit data through the internet. It is today the case for the historical actors.
d. The common and secured open standard of communication must offer an exhaustive model of data and which enable AIS to access exactly to the same data that the user on his bank’s website. Indeed, we have to keep in mind that the AIS and PIS’ job is to connect to the bank’s website as the user would do to simplify its path and thus, remove those data from the AIS or PIS would result in the de-struction of the reason why those actors exist.
e. The communication standards (as it is likely that there will be sev-eral) will have to put in place control systems of fraudulent access. It is a key element which will enable the AIS, PIS and ASPSP to guarantee the security of the system.
f. The ASPSP will only need to provide the following services in order to be compliant with the PSD 2 to answer to the user’s expectations :
o Provide a service enabling the AIS or the PIS to authentify itself from the service during the authentication of the client (for example via s SSL protocol);
o Provide an authentication system by SMS to the first au-thentication of a new IP address of the first time that an AIS or PIS authentifies itself for the client (similar system to the 3D Secure);
o OPTIONALLY : the ASPSP would be equipped of an au-thentication system like Open source Oauth Open ID Con-nect kind to enable the AIS or PIS to authenticate itself and the client.
o OPTIONALLY : the ASPSP may create an API according to classical data model from the market (for example WE-BOOB) to which the AIS or PIS could connect to recover the data, the API could also may be used within the website or the mobile application.
It has to be noted that at this stage Budget Insight proposes its services to ASPSP in order to accompany them in the transformations linked to the PSD 2 to enable those latter to implement secured and efficient exchange systems with the AIS and PIS.
16. For each agreed clarification suggested above on which you agree, what should they contain in your view in order to achieve an appropriate balance between harmonisation, innovation while preventing too divergent practical implementations by ASPSPs of the future requirements?
In order to achieve an appropriate balance between harmonisation, innova-tion while preventing too divergent practical implementations by ASPSs of the future requirements, the following conditions must be met :- Users should not need to use more elements to connect their ac-counts via an AIS or PIS than their banking credentials and a SMS validation or a code received on their mobile phone (physical to-kens seriously harm the fluidity);
- Once the connection with an AIS or PIS done, this connection should be persistant and should not require a new strong authenti-cation to each refreshment.
- The authentication path for AIS or PIS must the same than the one which is used by the user in a way that cutting one would result to cut the other, which will result in the fact that the bank could not avoid an AIS or PIS to connect unless this latter had been removed from the licensed AIS/PIS’ directory.
- The data to which AIS and PIS have access must be strictly the same than the ones to which the final client has his access.
Furthermore, the following elements should be taken into consideration :
- It should not be imposed to ASPS a particular technology nor a par-ticular way of functioning but it should be required from them some practices listed here above in order to let them some freedrom regarding their information system ;
- Existing systems should be used and which do not require a heavy implementation for ASPSP :
o SSL Protocol to identify AIS or PIS ;
o Keep the actual credentials ot ensure the connection;
o Use the SMS for strong authentication which is a system which ensure fluidity;
- The creation of API with a model of data type WEBOOB;
- The use of an Connect Open ID system could be implemented by the AIS or even provided by the AIS and could also be used for the authentication of the client ;
- Working with an AIS or PIS on the creation of their authentication systems or their APIs.
17. In your opinion, is there any standards (existing or in development) outlining aspects that could be common and open, which would be especially suitable for the purpose of ensuring secure communications as well as for the appropriate identification of PSPs taking into consideration the privacy dimension?
- Regarding the famous solutions that we prescribe : we can advise SSL protocols to make the data transited and to enable to ASPSP to recognize the AIS or PIS ;- For the strong customer authentication : we can quote the 3D Secure ;
- For secure and open standards of communications : in France, there is France connect and the open ID system to manage the authentica-tion.
But any of the actual solutions which constitute a simple way of au-thentication enable a full access to the data such as scrapping. In-deed, the Open Bank API or Castore solutions provide a data which is incomplete compare to WEBOOB or to the model of dada of AIS such as Budget Insight, the most important element being that the AIS must have the same access and the same quality of information to the data than the client when this latter accesses to his home banking in read-only mode.
18. How would these requirement for common and open standards need to be designed and maintained to ensure that these are able to securely integrate other innovative business models than the one explicitly mentioned under article 66 and 67 (e.g. issuing of own credentials by the AIS/PIS)?
It is necessary that the entities who design and who maintain those solu-tions be the AIS, PIS and banks because those are the first concerned by those topics and who have interest in investing in systems enabling the fluidity of the data. It has to be noted that AIS and PIS are today gateways for other innovative business models. Indeed, budget Insight rents its li-censed API to more than 30 accountability software publishers and to sev-eral Fintech around advice in asset management.Thus, AIS are already authentication API for the account of others Fintechs and by this way are at the heart of exchange and securing systems of bank-ing data for the account of innovative actors.
For a performing system, this latter must be based on existing and ap-proved technologies in order to guarantee the adequate security level and the fluidity of the system (conservation for the authentication of historical credentials, use of SMS on the customer’s mobile phone for the strong au-thentication, use of SSL protocols).
The notion of API and data recovery for the account of the client through a service platform is already a usage developed by AIS such as Budget In-sight through his API Budgea. The key of this model does not necessarily consist in a structured API which will be costly and impossible to integrate for all the banks but through authentication systems which ease and secure the communications between ASPSP, AIS and PIS.
The notion of open source is not necessarily mandatory, ASPSP should be able to choose. Having said that, it must be mandatory for the ASPSP that whatever the technology chosen, this latter complies with strong commit-ments provided by the PSD 2 and enable to all licensed AIS or PIS to con-nect on behalf of the client through an authentication path identical to the one the client would use in order to connect alone.
19. Do you agree that the e-IDAS regulation could be considered as a possible solution for facilitating the strong customer authentication, protecting the confidentiality and the integrity of the payment service users’ personalised security credentials as well as for common and secure open standards of communication for the purpose of identification, DP on future RTS on strong customer and secure communication under PSD2 31 authentication, notification, and information? If yes, please explain how. If no, please explain why.
By way of background, the e-IDAS Regulation:- “a. lays down the conditions under which Member States recognise electronic identification means of natural and legal persons falling under a notified electronic identification scheme of another Member State;
- b. sets out a supervisory and liability regime to enable qualified trust services providers to deliver, at domestic and cross-border level, qualified trust services with a high level of assurance for electronic transactions;
- c. establishes a legal framework for electronic signatures, electronic seals, electronic time stamps, electronic documents, electronic registered de-livery services and certificate services for website authentication; and
- d. is mandatory for cross-border access to public services in EU countries where eIDs are available. Yes, e-IDAS regulation could be considered as a possible solution for facilitating the strong customer authentication. “
Indeed, the notion of qualified trust services and trust service provider goes with the application of certain requirements and obligations that ensure high-level security of whatever qualified trust services and products are used or provided (not for all issues, but could be useful for the identifica-tion of the AIS, PIS providers towards the ASASPSPs for access to payment account information (exchange of electronic certificates)) :
- qualified electronic signature and licensed provider ;
- asymetric encryption ;
- authentication from the bank.
The e-IDAS regulation could be used but under the condition that it does not require strong customer authentication for any connection enaling to an AIS a refreshment of the data. E-IDAS aims to propose interoperability, which is a good thing and which ease the authentication of the user and guarantees the safety of data.
To develop the current models and to develop future models around bank-ing data, the fluidity and the rapidity of access to the data that historical AIS and PIS have implemented must be maintained.
20. Do you think in particular that the use of “qualified trust services” under e-IDAS regulation could address the risks related to the confidentiality, integrity and availability of PSCs between AIS, PIS providers and ASPSPs? If yes, please identify which services and explain how. If no, please explain why.
A qualified trust service provider “means a trust service provider who provides one or more qualified trust services and is granted the qualified status by the su-pervisory body;”.The requirements applicable to qualified trust services are detailed within the section 3 (“Qualified Trust Services”) of Chapter III (“Trust Services”).
More specifically, the article 24 (2) (“Requirements for qualified trust service providers”) provides that :
“2. A qualified trust service provider providing qualified trust services shall:
(a) inform the supervisory body of any change in the provision of its qualified trust services and an intention to cease those activities;
(b) employ staff and, if applicable, subcontractors who possess the necessary exper-tise, reliability, experience, and qualifications and who have received appropriate training regarding security and personal data protection rules and shall apply administrative and management procedures which correspond to European or in-ternational standards;
(c) with regard to the risk of liability for damages in accordance with Article 13, maintain sufficient financial resources and/or obtain appropriate liability insur-ance, in accordance with national law;
(d) before entering into a contractual relationship, inform, in a clear and compre-hensive manner, any person seeking to use a qualified trust service of the precise terms and conditions regarding the use of that service, including any limitations on its use;
(e) use trustworthy systems and products that are protected against modification and ensure the technical security and reliability of the processes supported by them;
(f) use trustworthy systems to store data provided to it, in a verifiable form so that:
(i) they are publicly available for retrieval only where the consent of the person to whom the data relates has been obtained,
(ii) only authorised persons can make entries and changes to the stored da-ta, (iii) the data can be checked for authenticity;
(g) take appropriate measures against forgery and theft of data;
(h) record and keep accessible for an appropriate period of time, including after the activities of the qualified trust service provider have ceased, all relevant information concerning data issued and received by the qualified trust service provider, in par-ticular, for the purpose of providing evidence in legal proceedings and for the pur-pose of ensuring continuity of the service. Such recording may be done electroni-cally;
(i) have an up-to-date termination plan to ensure continuity of service in accord-ance with provisions verified by the supervisory body under point (i) of Article 17(4);
(j) ensure lawful processing of personal data in accordance with Directive 95/46/EC;
(k) in case of qualified trust service providers issuing qualified certificates, establish and keep updated a certificate database.”
The use of “qualified trust services” under e-IDAS regulation could address the risks related to the confidentiality, integrity and availability of PSCs between AIS, PIS providers and ASASPSPs for payment services, provided that the fluidity and the rapidity of access to the data that historical AIS and PIS have implemented must be maintained.