Response to discussion on RTS on strong customer authentication and secure communication under PSD2
Go back
The objective of the newly published Payment Services Directive 2 (PSD2) is to regulate new AIS and PIS providers. These providers connect to traditional financial service companies such as banks, insurance companies and payment operators, allowing users to centrally manage their multiple accounts. The strong popularity and rapid growth of AIS and PIS service offerings show that they respond to real market needs.
In the French B2B market, over 20.000 companies and 40 management software providers use this type of service. The market is growing at 10% per month.
Overall, including the B2C market, there are 2 million users of AIS type services.
Advances in computer technology have allowed new and largely unregulated services to access users’ financial accounts automatically on their behalf. Users record their web credentials, used to access financial websites over the Internet, on the AIS and PIS sites, and these automate the login procedure, and retrieve on a regular basis information such as statements and transaction records. The simplicity of adopting these services and the increasing number of accounts per user are the drivers of their success. Though this approach is used primarily for Access (AIS), Payment initiation (PIS) could use a similar mechanism.
The financial sector has always been closely regulated in order to protect both users, service providers and the system as a whole. However a fine balance must be achieved between the increased user complexity and an efficient response to user needs. Excessive constraints and user complexity reduce adoption of regulated services and push adoption of unregulated ones, namely services provided over the Internet from outside the EU legal space. The consequences of excessive regulation will be to stifle innovation in the EU, while not diminishing risks posed by non EU services and favoring the emergence of dominant, non-EU, non-regulated players.
In answering the question of how to maintain the “balance between harmonisation and innovation”, we have to start from user needs and usage. This is healthy and efficient since usage always wins out over time. The issues are summarized below. Based on this a recommended approach to a future secure and open solution is outlined.
The CONTEXT and issues can be summarized as follows:
-Most users today can access their payment or bank accounts online with a username and password (or other means of authentication) at least for the purposes of obtaining their bank statement information.
-Users benefit from the ease of registering their access information in one place, online, in order for a service provider to manage the retrieval of their information automatically. Presently the AIS and PIS providers have a ‘mandate’ (implicit or explicit) from users to act on their behalf in obtaining information from users’ multiple accounts.
-Currently, Account Holders (eg. Banks) do not have a means of identifying the AIS or PIS service provider, and do not have knowledge of the above-mentioned mandate, so that controlling this mandate is impossible.
-Added security should be achieved without affecting the fluidity of the user experience and the innovation dynamics that aggregation services provide.
RECOMMENDED APPROACH :
-From the above we can see that the user’s identity is known by the Account Holder, who provides the required means of authentication. It should therefore not be necessary to require the user to undergo a new identity verification (‘Registration’ in digital identity terms). The principle is that the required method of authentication should not be more demanding than that used by the Account Holder site.
-When setting up the AIS service, the user should be able to confirm to the Account Holder - in a workflow that is integrated with the Aggregators’ service - that he authorizes the ‘Aggregation’ service provider to retrieve information on his behalf. He confirms this using the authentication information provided - and thus recognizable - by the Account Holder, in order to be duly identified and to signify his consent. This should be done once, and remain valid for an extended period. This last point is a prerequisite to the need for automation. Requiring the user to enter his password every time the Aggregator retrieves information would be totally inefficient, contrary to what users do today and would destroy the desired innovation.
-The AIS service has to be explicitly identifiable by the Account Holder, each time the Aggregator’s systems connect to the Account Holder’s systems. This will require that the Aggregator register a digital identity (eg an SSL or similar certificate) with the Account Holder or with a central directory automatically contactable by the Account Holder. Such a directory could follow the e-Idas model with linked national directories managed by the states or national regulatory bodies, under the supervision of an EU regulatory body (for example the European Banking Authority).
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.
No additional comments.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?
No additional comments.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?
No additional comments.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)?
No additional comments.5. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to dynamic linking?
No additional comments.6. In your view, which solutions for mobile devices fulfil both the objective of independence and dynamic linking already today?
No additional comments.7. Do you consider the clarifications suggested regarding the potential exemptions to strong customer authentication, to be useful?
No additional comments.8. Are there any other factors the EBA should consider when deciding on the exemptions applicable to the forthcoming regulatory technical standards?
No additional comments.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?
No additional comments.10. Do you consider the clarification suggested regarding the protection of users personalised security credentials to be useful?
No additional comments.11. What other risks with regard to the protection of users’ personalised security credentials do you identify?
No additional comments.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?
No additional comments.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?
No additional comments.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?
No additional comments.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?
No additional comments.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?
The answers below express the views of the Working Group on e-Finance/Account Aggregation, at the Federation of Trusted Third Parties (FNTC). We are an international professional association, based in Paris, of more than 100 members including: Regulated Professions (eg. Chartered Accountants, Bailiffs), providers of Digital Trusted Third Party services (eg. Certificate Authorities, Certified Digital Archiving, Time-stamping Authorities), Banks and other Financial Services Providers, Software companies (eg. Payments Software, Management Software), Consulting Firms, Legal Firms and independent experts in the area of Digital Trust.The objective of the newly published Payment Services Directive 2 (PSD2) is to regulate new AIS and PIS providers. These providers connect to traditional financial service companies such as banks, insurance companies and payment operators, allowing users to centrally manage their multiple accounts. The strong popularity and rapid growth of AIS and PIS service offerings show that they respond to real market needs.
In the French B2B market, over 20.000 companies and 40 management software providers use this type of service. The market is growing at 10% per month.
Overall, including the B2C market, there are 2 million users of AIS type services.
Advances in computer technology have allowed new and largely unregulated services to access users’ financial accounts automatically on their behalf. Users record their web credentials, used to access financial websites over the Internet, on the AIS and PIS sites, and these automate the login procedure, and retrieve on a regular basis information such as statements and transaction records. The simplicity of adopting these services and the increasing number of accounts per user are the drivers of their success. Though this approach is used primarily for Access (AIS), Payment initiation (PIS) could use a similar mechanism.
The financial sector has always been closely regulated in order to protect both users, service providers and the system as a whole. However a fine balance must be achieved between the increased user complexity and an efficient response to user needs. Excessive constraints and user complexity reduce adoption of regulated services and push adoption of unregulated ones, namely services provided over the Internet from outside the EU legal space. The consequences of excessive regulation will be to stifle innovation in the EU, while not diminishing risks posed by non EU services and favoring the emergence of dominant, non-EU, non-regulated players.
In answering the question of how to maintain the “balance between harmonisation and innovation”, we have to start from user needs and usage. This is healthy and efficient since usage always wins out over time. The issues are summarized below. Based on this a recommended approach to a future secure and open solution is outlined.
The CONTEXT and issues can be summarized as follows:
-Most users today can access their payment or bank accounts online with a username and password (or other means of authentication) at least for the purposes of obtaining their bank statement information.
-Users benefit from the ease of registering their access information in one place, online, in order for a service provider to manage the retrieval of their information automatically. Presently the AIS and PIS providers have a ‘mandate’ (implicit or explicit) from users to act on their behalf in obtaining information from users’ multiple accounts.
-Currently, Account Holders (eg. Banks) do not have a means of identifying the AIS or PIS service provider, and do not have knowledge of the above-mentioned mandate, so that controlling this mandate is impossible.
-Added security should be achieved without affecting the fluidity of the user experience and the innovation dynamics that aggregation services provide.
RECOMMENDED APPROACH :
-From the above we can see that the user’s identity is known by the Account Holder, who provides the required means of authentication. It should therefore not be necessary to require the user to undergo a new identity verification (‘Registration’ in digital identity terms). The principle is that the required method of authentication should not be more demanding than that used by the Account Holder site.
-When setting up the AIS service, the user should be able to confirm to the Account Holder - in a workflow that is integrated with the Aggregators’ service - that he authorizes the ‘Aggregation’ service provider to retrieve information on his behalf. He confirms this using the authentication information provided - and thus recognizable - by the Account Holder, in order to be duly identified and to signify his consent. This should be done once, and remain valid for an extended period. This last point is a prerequisite to the need for automation. Requiring the user to enter his password every time the Aggregator retrieves information would be totally inefficient, contrary to what users do today and would destroy the desired innovation.
-The AIS service has to be explicitly identifiable by the Account Holder, each time the Aggregator’s systems connect to the Account Holder’s systems. This will require that the Aggregator register a digital identity (eg an SSL or similar certificate) with the Account Holder or with a central directory automatically contactable by the Account Holder. Such a directory could follow the e-Idas model with linked national directories managed by the states or national regulatory bodies, under the supervision of an EU regulatory body (for example the European Banking Authority).