Response to discussion on RTS on strong customer authentication and secure communication under PSD2
Go back
The EACB welcomes the opportunity to participate in the consultation launched by the European Banking Authority regarding the Discussion Paper on strong customer authentication and secure communication under PSD2.
The EACB fully endorses the aims of the PSD2 especially to increase innovation in payments and to make payment more convenient. We fully recognize that by leveraging the creativity of third parties (esp. “FinTech”s), these aims may potentially be achieved quicker than by each Account Servicing Payment Services Provider (ASPSP) pursuing its own development.
Since there is general agreement that the introduction of third party payment providers clearly must be done in a fair, secure, scalable, non-fragmented way without compromising the authentications measures designed by ASPSP and the credentials provided to the Payment Service User (PSU) in this context, we very much welcome the opportunity to share our views on how this can best be achieved.
We acknowledge the principles in the PSD2 that access is to be granted to Payment Initiation Services (PIS) providers, Account Information Services (AIS) providers and Payment Services Providers issuing card-based payment instruments (PIIS) without discrimination (i.e. to all who use online banking). This, together with the allocation of liabilities emerging from PSD2 and the fact that ASPSPs are the first port of call for problems that arise, gives particular importance to the topics of secure access and authentication. However, it should be recalled that the overall objective of security has to be achieved through a mix of different measures and that authentication and communication procedures are therefore only one part of this set.
In order to achieve the objective of the PSD2 (innovative new services through third parties) and ensure the goal that we surely all must have (no fraud), we strongly suggest that those who are experts in the field and closest to the latest fraud and attack developments and those that are the first port of call in resolving issues around unauthorised transactions should be allowed some freedom in defining the authentication and security mechanisms they need to use to avoid these from happening.
There are inherent risks attached to specifying too many details of authentication and security in legislation . They will take x months to develop, x months to consult, x months to implement, will stay in place until the next revision in 2 years - and will likely be outdated next week. Fraudsters are incredibly flexible in their attack vectors, their vulnerability exploitations, their methodology, the latest technology employed. ASPSP will provide the authentication procedures which will be used by PIS and AIS providers, ASPSP will also be the first port of call for issues arising with activities of such PIS and AIS providers, thus we believe that ASPSP should be able to react flexibly according to conditions and not be constrained by static, prescriptive and over-detailed regulations.
A case in point where legislation already is in danger of going awry is the current PSD 2 definition of strong authentication which refers to “2-Factor” recommendation. While this recommendation corresponds to the commonly accepted approach as per now, and is certainly better than single static passwords, it nevertheless raises questions in a fast evolving technical environment. What can be considered as a factor? What is today seen as a factor but could be insufficient tomorrow. Are there solutions arising that could be alternative ones to the two factor approach?
In the context of the development of the Regulatory Technical Standards (RTS), it is important to realise that an ASPSP does not limit its efforts to secure the funds of its customers to the implementation of a certain authentication mechanism. While authentication is certainly an important factor, it is part of an overall risk based security objective and may vary according to findings from other security measures such as monitoring the PSU behaviour. For example if a user orders and buys his coffee in the same location every weekday with the same Starbucks app, a “½”-Factor authentication may be sufficient. On the other hand if he once in a lifetime buys a house, maybe “7” Factors should be applied (dynamic risk based authentication).
We would suggest that laying down the rules on the number of factors, the nature and property of credentials or the exceptions and rules under which they are to applied into too much detail increases the already dramatic risk of cybercrime. If organized crime has transparent access to the rules of how security is managed, they will very quickly develop appropriate dynamic attacks which the financial services industry, constrained by static rules laid down by law, cannot respond to. The ASPSPs must be able to configure their security measures and dynamically respond according to current risk vectors, attack scenarios, technological developments, changing user habits etc.
Also the PSD2 and the Discussion Paper speak largely of “credentials” (suggesting user-ids, passwords, TAN codes etc.). This term may need to be adjusted to future-oriented authentication methods such as those based on tokenization, open authentication etc. (such as is employed widely across the internet with PayPal, Uber, Facebook etc.).
Instead “Principle Based Regulation” is surely called for which lays down principles and intent but leaves the market the possibility to adjust to developments and customer behaviour based on its own risk analysis. The main principles are indeed already laid down in PSD2: no discrimination, secure communication, no storing and passing on of sensitive data to others, reliable identification of third parties etc. This is largely sufficient and does not require huge RTS with immense detailing. At the same time, a level playing field between different actors has to be ensured.
Accordingly, the EACB considers that the RTS should only seek to set minimum requirements on authentication and communication addressing those areas where further clarification is needed:
1) The principle, already enshrined in PSD2, that TPPs rely on the ASPSP authentication should be given further principles of clarity. In our understanding the TPP, unless it chooses to issue its own credentials and do its own authentication, therefore needs not worry about details of authentication – the authentication will be done directly between the credential issuer (bank) and the credential user. The dialogue/communication must go directly between these parties (e.g. via direct exchange of cryptographic token between PSU and ASPSP, or via rerouting of user to bank). As one of the principles we strongly suggest there must not be overlay (e.g. screen scraping, user impersonation) solutions, as these assume something like a “secure tunnel” through a TPP which does not exist in reality.
2) Also requiring clarification is what to do in case TPPs choose not to re-use the ASPSPs credentials but to issue their own. In this case, as the ASPSP is not aware of the credentials being used by the PSU or of the authentication process being applied by the TPP, the ASPSP has no means to control the access to its client’s account and has to be exempted from being the first port of call and any liabilities for issues arising from TPP involvement by the PSU. In addition, ASPSPs should be allowed to do additional checks in order to know if a given “access” or “payment initiation” is indeed mandated and consented to by its customer.
3) Another principle that should in our opinion be clarified is that the ASPSP should be able to verify the legality/license of any TPP in a reliable way. For that purpose, the register that EBA wil develop should:
• be able to serve as a single source (e.g. could be developed by EBA or merely consolidating the information of national registers) access point for ASPSPs to access information on licensed TPPs;
• not only provide the TPPs name for the PSU to check (which is nice to have but serves no real security function) but must contain a digital certificate issued by a trust service provider (in the context of regulation 910/2014). This is needed to allow the ASPSPs to check online and in real time to see if the TPP is really who they say they are and is really currently licensed for AIS and/or PIS and/or PIIS;
• explicitly distinguish between different licences for different TPPs;
• provide information on an open-acess basis while being technically manageable i.e. provide a downloadable file that can be integrated into ASPSP IT systems or hold plain text in machine readable form.
In addition, the register would need to be designed in a way that ASPSP can rely on customers’ awareness of its content.
Having said that, the register containing all this information cannot help banks in addressing the possible insolvency of a TPP and further mechanisms need to be worked out to address such situation.
4) As regards the development of TPPs services, and the balance to be struck between harmonisation (to avoid 7000 ASPSP offering different solutions to different TPPs) and innovation, the EACB would argue that these developments should be driven by the principles of a Market Economy and result from interactions between supply and demand. Whilst recognising the need for governance structures, the RTS should not strive for the development of one single pan-European approach, standards or specific governance. Indeed, trying to do so will take the market years of work fraught with compromises distracting from the real innovation that is sought after. We believe that different approaches to the development of standards of communication between the different PSPs in the market should be allowed to develop such as:
• National communities developing single interfaces;
• Subgroups of ASPSPs developing solutions;
• Other service providers developing bundled access solutions to groups of ASPSPs.
Finally we wish to make a short remark on the topic of “synergies with e-IDAS”. We welcome, of course, the development of professional identity solutions and in the vein of the single European Market it is clearly apposite to think about mutual recognition of identity across Member States. However it must be noted that electronic identities (and seals, etc.) as currently defined are only one mechanism of ensuring identity and authentication. These digital identities are typically designed for government or public services and may be a little heavy handed (certified signature, qualified registered delivery service, etc.) for some authentication scenarios. Again the industry should be free to choose which authentication and identification methods it considers appropriate and should have the flexibility, for example, to choose much lighter methods for simple transaction authentication than those designed for legal signatory of a contractual document in public procurement with a government agency.
Answer to question 1:
There are no additions to Article 97(1) (c). The Article is already that well-spaced that all risks which are not mentioned in point (a) and (b) and which contain a potential risk concerning payment fraud are covered.
In respect of future development in our point of view data could also be a possession element. To be able to check the data sufficiently through the PSU, additional and different precautionary measures are necessary.
What form the customer authentication source element has to take is generally determined by the ASPSP based on a risk based approach which can vary over time.
- 42 B: we could agree with the proposal on the condition that the addition of a new entry to the whitelist has itself been subject to strong authentication. Additionally, it would be useful to explain that the consultative services are not meant to involve AIS and that it concerns only the PSU consulting his account;
- 42 E: as regards the reference to ‘’services with no display of sensitive payment data’’. This reference raises many questions: what data can be disclosed? what payment data is considered as being sensitive? What about data such as remittance information that reveals information on a person that is not party to the contract between the ASPSP and the PSU.
Finally, the EACB would argue that the examples in point 42 are indeed mere examples and that they should not be considered as an exhaustive list and would ask that, if the ASPSP has reasons for suspicion, it should be allowed to apply strong authentication even to the mentioned transactions (e.g. low-value payments that occur frequently in a short time therewith clocking up larger amounts of money).
- According to the PSD there are several possible scenarios:
o AIS/PIS re-using the ASPSP credentials (not accessible to third parties);
o AIS/PIS providers issuing their own credentials. In this case, as the ASPSP is not aware of the credentials being used by the PSU or of the authentication process being applied by the TPP, the ASPSP has no means to control the access to its client’s account and has to be exempted from being the first port of call and any liabilities for issues arising from TPP involvement by the PSU. In addition, ASPSPs should be allowed to do additional checks in order to know if a given “access” or “payment initiation” is indeed mandated and consented to by its customer;
o A specific analysis of these scenario’s and their consequences would be helpful.
- To make a clear distinction between what applies to AIS and PIS providers and ASPSP;
- In Point 52. i, it is stated that ‘’the creation, issuance, modification and re-issuance of the credentials needs to be secured’’. We consider that the nature of the topic requires a clear definition of the concept ‘’secured’;
- This part of the Discussion Paper should also address the revocation of the credentials by the user of the ASPSP.
Finally, it is important to take into account that ASPSP are already subject to regulatory requirements for safe handling and the protection of personal access data.
A clear distinction between the requirements for AIS and PIS or ASPSP is desired.
Generally, it needs to be remarked that any kind of static credential cannot fulfil high security requirements. It can be stolen and misused at any segment of the enrolment or payment chain. Therefore it shall not be acceptable for any kind of transaction (exceptions may apply see no. 7). For pure read only access to account information it may be sufficient.
At the moment the customer and his used device are the biggest risk in the payment chain (e.g. social engineering).
In future, there will be additional factors which have impact on the confidentiality of these data. For example, there will be an additional interface between the user and the ASPSP. As the ASPSP has little influence on the risks of AIS or PIS these should be specially addressed in the RTS.
Regarding standards of communication, the EACB believes that – without the possibility to conclude contracts with AIS, PIS and PIIS providers and therewith the possibility to exchange certificates - the central Register that EBA (or another regulatory) will provide of licensed AIS, PIS and PIIS providers should fulfil the function of issuing certificates for the identification of AIS, PIS and PIIS providers towards ASPSP. Having said that, the register containing all this information cannot help banks in addressing the possible insolvency of a TPP and further mechanisms need to be worked out to address such situation.
More generally, as regards the development of TPPs services, and the balance to be struck between harmonisation (to avoid 7000 ASPSP offering different solutions to different TPPs) and innovation, the EACB would argue that these developments should be driven by the principles of a Market Economy and result from interactions between supply and demand. The RTS should not encourage the development of one single pan-European approach, standards or specific governance. Indeed, trying to do so will take the market years of work fraught with compromises distracting from the real innovation that is sought after. We believe that different approaches to the development of standards of communication between the different PSPs in the market should be allowed to develop such as:
• National communities developing single interfaces;
• Subgroups of ASPSPs developing solutions;
• Other service providers developing bundled access solutions to groups of ASPSPs (see also our general comment).
As for the design and the maintenance of the common and open standards, we would consider that any interface used should be based on open standards. However we would warn against the establishment of procedurally heavy EU wide governance mechanisms at this stage. We believe that the market should be allowed to develop based on a limited number of communication standards through clusters of ASPSP and TPPs – as described in our general comments and under question 16) with the potential involvement of aggregators.
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.
Please, find here below the general comments that the EACB would like to put forward regarding the whole Discussion Paper. Following the general comments, you will also find our answer to question 1 (bottom of the answer).The EACB welcomes the opportunity to participate in the consultation launched by the European Banking Authority regarding the Discussion Paper on strong customer authentication and secure communication under PSD2.
The EACB fully endorses the aims of the PSD2 especially to increase innovation in payments and to make payment more convenient. We fully recognize that by leveraging the creativity of third parties (esp. “FinTech”s), these aims may potentially be achieved quicker than by each Account Servicing Payment Services Provider (ASPSP) pursuing its own development.
Since there is general agreement that the introduction of third party payment providers clearly must be done in a fair, secure, scalable, non-fragmented way without compromising the authentications measures designed by ASPSP and the credentials provided to the Payment Service User (PSU) in this context, we very much welcome the opportunity to share our views on how this can best be achieved.
We acknowledge the principles in the PSD2 that access is to be granted to Payment Initiation Services (PIS) providers, Account Information Services (AIS) providers and Payment Services Providers issuing card-based payment instruments (PIIS) without discrimination (i.e. to all who use online banking). This, together with the allocation of liabilities emerging from PSD2 and the fact that ASPSPs are the first port of call for problems that arise, gives particular importance to the topics of secure access and authentication. However, it should be recalled that the overall objective of security has to be achieved through a mix of different measures and that authentication and communication procedures are therefore only one part of this set.
In order to achieve the objective of the PSD2 (innovative new services through third parties) and ensure the goal that we surely all must have (no fraud), we strongly suggest that those who are experts in the field and closest to the latest fraud and attack developments and those that are the first port of call in resolving issues around unauthorised transactions should be allowed some freedom in defining the authentication and security mechanisms they need to use to avoid these from happening.
There are inherent risks attached to specifying too many details of authentication and security in legislation . They will take x months to develop, x months to consult, x months to implement, will stay in place until the next revision in 2 years - and will likely be outdated next week. Fraudsters are incredibly flexible in their attack vectors, their vulnerability exploitations, their methodology, the latest technology employed. ASPSP will provide the authentication procedures which will be used by PIS and AIS providers, ASPSP will also be the first port of call for issues arising with activities of such PIS and AIS providers, thus we believe that ASPSP should be able to react flexibly according to conditions and not be constrained by static, prescriptive and over-detailed regulations.
A case in point where legislation already is in danger of going awry is the current PSD 2 definition of strong authentication which refers to “2-Factor” recommendation. While this recommendation corresponds to the commonly accepted approach as per now, and is certainly better than single static passwords, it nevertheless raises questions in a fast evolving technical environment. What can be considered as a factor? What is today seen as a factor but could be insufficient tomorrow. Are there solutions arising that could be alternative ones to the two factor approach?
In the context of the development of the Regulatory Technical Standards (RTS), it is important to realise that an ASPSP does not limit its efforts to secure the funds of its customers to the implementation of a certain authentication mechanism. While authentication is certainly an important factor, it is part of an overall risk based security objective and may vary according to findings from other security measures such as monitoring the PSU behaviour. For example if a user orders and buys his coffee in the same location every weekday with the same Starbucks app, a “½”-Factor authentication may be sufficient. On the other hand if he once in a lifetime buys a house, maybe “7” Factors should be applied (dynamic risk based authentication).
We would suggest that laying down the rules on the number of factors, the nature and property of credentials or the exceptions and rules under which they are to applied into too much detail increases the already dramatic risk of cybercrime. If organized crime has transparent access to the rules of how security is managed, they will very quickly develop appropriate dynamic attacks which the financial services industry, constrained by static rules laid down by law, cannot respond to. The ASPSPs must be able to configure their security measures and dynamically respond according to current risk vectors, attack scenarios, technological developments, changing user habits etc.
Also the PSD2 and the Discussion Paper speak largely of “credentials” (suggesting user-ids, passwords, TAN codes etc.). This term may need to be adjusted to future-oriented authentication methods such as those based on tokenization, open authentication etc. (such as is employed widely across the internet with PayPal, Uber, Facebook etc.).
Instead “Principle Based Regulation” is surely called for which lays down principles and intent but leaves the market the possibility to adjust to developments and customer behaviour based on its own risk analysis. The main principles are indeed already laid down in PSD2: no discrimination, secure communication, no storing and passing on of sensitive data to others, reliable identification of third parties etc. This is largely sufficient and does not require huge RTS with immense detailing. At the same time, a level playing field between different actors has to be ensured.
Accordingly, the EACB considers that the RTS should only seek to set minimum requirements on authentication and communication addressing those areas where further clarification is needed:
1) The principle, already enshrined in PSD2, that TPPs rely on the ASPSP authentication should be given further principles of clarity. In our understanding the TPP, unless it chooses to issue its own credentials and do its own authentication, therefore needs not worry about details of authentication – the authentication will be done directly between the credential issuer (bank) and the credential user. The dialogue/communication must go directly between these parties (e.g. via direct exchange of cryptographic token between PSU and ASPSP, or via rerouting of user to bank). As one of the principles we strongly suggest there must not be overlay (e.g. screen scraping, user impersonation) solutions, as these assume something like a “secure tunnel” through a TPP which does not exist in reality.
2) Also requiring clarification is what to do in case TPPs choose not to re-use the ASPSPs credentials but to issue their own. In this case, as the ASPSP is not aware of the credentials being used by the PSU or of the authentication process being applied by the TPP, the ASPSP has no means to control the access to its client’s account and has to be exempted from being the first port of call and any liabilities for issues arising from TPP involvement by the PSU. In addition, ASPSPs should be allowed to do additional checks in order to know if a given “access” or “payment initiation” is indeed mandated and consented to by its customer.
3) Another principle that should in our opinion be clarified is that the ASPSP should be able to verify the legality/license of any TPP in a reliable way. For that purpose, the register that EBA wil develop should:
• be able to serve as a single source (e.g. could be developed by EBA or merely consolidating the information of national registers) access point for ASPSPs to access information on licensed TPPs;
• not only provide the TPPs name for the PSU to check (which is nice to have but serves no real security function) but must contain a digital certificate issued by a trust service provider (in the context of regulation 910/2014). This is needed to allow the ASPSPs to check online and in real time to see if the TPP is really who they say they are and is really currently licensed for AIS and/or PIS and/or PIIS;
• explicitly distinguish between different licences for different TPPs;
• provide information on an open-acess basis while being technically manageable i.e. provide a downloadable file that can be integrated into ASPSP IT systems or hold plain text in machine readable form.
In addition, the register would need to be designed in a way that ASPSP can rely on customers’ awareness of its content.
Having said that, the register containing all this information cannot help banks in addressing the possible insolvency of a TPP and further mechanisms need to be worked out to address such situation.
4) As regards the development of TPPs services, and the balance to be struck between harmonisation (to avoid 7000 ASPSP offering different solutions to different TPPs) and innovation, the EACB would argue that these developments should be driven by the principles of a Market Economy and result from interactions between supply and demand. Whilst recognising the need for governance structures, the RTS should not strive for the development of one single pan-European approach, standards or specific governance. Indeed, trying to do so will take the market years of work fraught with compromises distracting from the real innovation that is sought after. We believe that different approaches to the development of standards of communication between the different PSPs in the market should be allowed to develop such as:
• National communities developing single interfaces;
• Subgroups of ASPSPs developing solutions;
• Other service providers developing bundled access solutions to groups of ASPSPs.
Finally we wish to make a short remark on the topic of “synergies with e-IDAS”. We welcome, of course, the development of professional identity solutions and in the vein of the single European Market it is clearly apposite to think about mutual recognition of identity across Member States. However it must be noted that electronic identities (and seals, etc.) as currently defined are only one mechanism of ensuring identity and authentication. These digital identities are typically designed for government or public services and may be a little heavy handed (certified signature, qualified registered delivery service, etc.) for some authentication scenarios. Again the industry should be free to choose which authentication and identification methods it considers appropriate and should have the flexibility, for example, to choose much lighter methods for simple transaction authentication than those designed for legal signatory of a contractual document in public procurement with a government agency.
Answer to question 1:
There are no additions to Article 97(1) (c). The Article is already that well-spaced that all risks which are not mentioned in point (a) and (b) and which contain a potential risk concerning payment fraud are covered.
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?
Generally speaking independent tokens which are not connected to any other hardware in order to work, with a fixed firmware that cannot be updated by the user are preferable. Having said that, software solutions that are located in a specific trusted execution environment that cannot be altered by the user or software outside the trusted environment, coupled with additional security measures can also be used.In respect of future development in our point of view data could also be a possession element. To be able to check the data sufficiently through the PSU, additional and different precautionary measures are necessary.
What form the customer authentication source element has to take is generally determined by the ASPSP based on a risk based approach which can vary over time.
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?
Behavioural authentication is still an early technology, it has to be monitored and tested in detail in combination with a specific threat model, but it could be a solution which combines strong security with user convenience. It would seem too early to base the inherence elements on behavioural data only. Behavioral authentication can only be used in combination with other elements.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)?
Mobile devices could be considered as insecure and not suitable for an independent channel but they could still be used in combination with additional security measures (e.g. the device supports trusted execution environments). These additional security measures could be for instance the prior enrollment of the user’s device when he/she enters into the relation with the ASPSP or reinforced fraud management.5. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to dynamic linking?
Dynamic linking must include amount, target account and a timestamp (the latter in order to trace a transaction in case of error handling).6. In your view, which solutions for mobile devices fulfil both the objective of independence and dynamic linking already today?
For example, solutions such as one time TAN transmitted through sms. The transaction number is transmitted to the mobile phone. Additionally the included TAN is just valid for the instructed transaction. This meets the requirements of independence and dynamic linking.7. Do you consider the clarifications suggested regarding the potential exemptions to strong customer authentication, to be useful?
The EACB agrees that there can be low risk transactions like the ones mentioned which would justify a reduced authentication security level. And we would add recurring transactions provided the first one has been subject to strong customer authentication. Having said that we would welcome further clarity regarding point 42. B and E as follows:- 42 B: we could agree with the proposal on the condition that the addition of a new entry to the whitelist has itself been subject to strong authentication. Additionally, it would be useful to explain that the consultative services are not meant to involve AIS and that it concerns only the PSU consulting his account;
- 42 E: as regards the reference to ‘’services with no display of sensitive payment data’’. This reference raises many questions: what data can be disclosed? what payment data is considered as being sensitive? What about data such as remittance information that reveals information on a person that is not party to the contract between the ASPSP and the PSU.
Finally, the EACB would argue that the examples in point 42 are indeed mere examples and that they should not be considered as an exhaustive list and would ask that, if the ASPSP has reasons for suspicion, it should be allowed to apply strong authentication even to the mentioned transactions (e.g. low-value payments that occur frequently in a short time therewith clocking up larger amounts of money).
8. Are there any other factors the EBA should consider when deciding on the exemptions applicable to the forthcoming regulatory technical standards?
From a present-day perspective no other factors are known.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?
The criteria mentioned are reasonable whereby (b) has limited effectiveness as malware typically acts from the same resources as a legitimate user. In any case ASPSPs should be allowed to use additional external threat intelligence information (IOCs), coming from peer groups or dedicated sensors/honeypots to enrich the quality of the transaction risk assessment. In addition, any provision related to transaction risk analysis should be defined considering the fast changing nature of the current payments environment.10. Do you consider the clarification suggested regarding the protection of users personalised security credentials to be useful?
The suggestion regarding the protection of the users’ personalised security credentials is not clear enough. First of all, the uncertainty created by recital 69, art 66.2.b and 67.2.b. should be resolved by the RTS. We would ask the EBA to additionally develop on the following points:- According to the PSD there are several possible scenarios:
o AIS/PIS re-using the ASPSP credentials (not accessible to third parties);
o AIS/PIS providers issuing their own credentials. In this case, as the ASPSP is not aware of the credentials being used by the PSU or of the authentication process being applied by the TPP, the ASPSP has no means to control the access to its client’s account and has to be exempted from being the first port of call and any liabilities for issues arising from TPP involvement by the PSU. In addition, ASPSPs should be allowed to do additional checks in order to know if a given “access” or “payment initiation” is indeed mandated and consented to by its customer;
o A specific analysis of these scenario’s and their consequences would be helpful.
- To make a clear distinction between what applies to AIS and PIS providers and ASPSP;
- In Point 52. i, it is stated that ‘’the creation, issuance, modification and re-issuance of the credentials needs to be secured’’. We consider that the nature of the topic requires a clear definition of the concept ‘’secured’;
- This part of the Discussion Paper should also address the revocation of the credentials by the user of the ASPSP.
Finally, it is important to take into account that ASPSP are already subject to regulatory requirements for safe handling and the protection of personal access data.
11. What other risks with regard to the protection of users’ personalised security credentials do you identify?
There are no additional risks. However, attention should be paid to “51 e” according to the document. An additional TPP in the payment chain leads to additional risks (man in the middle attacks).A clear distinction between the requirements for AIS and PIS or ASPSP is desired.
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?
The enrolment phase is one of the more important phases of the whole transaction process and the EBA is right in addressing it. Different open standards are already available. In order to provide a consistent answer to the question however, EBA should define which relations are envisaged in the framework of this question (PSU to ASPSP, PSU to PI/AIS providers, PI/AIS providers to ASPSP).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, based on the available information we could not mention any other alternatives.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 risk may potentially arise at any segment of the payment chain. Fraudsters will always use the weakest segment and actors in the chain to breach security rules. Any regulatory development should avoid the introduction of any additional weak segment to the chain.Generally, it needs to be remarked that any kind of static credential cannot fulfil high security requirements. It can be stolen and misused at any segment of the enrolment or payment chain. Therefore it shall not be acceptable for any kind of transaction (exceptions may apply see no. 7). For pure read only access to account information it may be sufficient.
At the moment the customer and his used device are the biggest risk in the payment chain (e.g. social engineering).
In future, there will be additional factors which have impact on the confidentiality of these data. For example, there will be an additional interface between the user and the ASPSP. As the ASPSP has little influence on the risks of AIS or PIS these should be specially addressed in the RTS.
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?
The analysis should be extended to include the activities of Payment Service Providers issuing card-based payment instruments (PIIS). This seems particularly relevant for point 63 . (b) and (c).Regarding standards of communication, the EACB believes that – without the possibility to conclude contracts with AIS, PIS and PIIS providers and therewith the possibility to exchange certificates - the central Register that EBA (or another regulatory) will provide of licensed AIS, PIS and PIIS providers should fulfil the function of issuing certificates for the identification of AIS, PIS and PIIS providers towards ASPSP. Having said that, the register containing all this information cannot help banks in addressing the possible insolvency of a TPP and further mechanisms need to be worked out to address such situation.
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?
Regarding point 63.e and the access by AIS providers it is important to recall that recital 28 refers to “ The payment service user is thus able to have an overall view of its financial situation immediately at any given moment”. This does not require the ASPSP to make available to a AIS a full historical overview of transactions having taken place on the account(s) and that a too frequent access by AIS providers will trigger a reaction to a denial of service attack (DDos).More generally, as regards the development of TPPs services, and the balance to be struck between harmonisation (to avoid 7000 ASPSP offering different solutions to different TPPs) and innovation, the EACB would argue that these developments should be driven by the principles of a Market Economy and result from interactions between supply and demand. The RTS should not encourage the development of one single pan-European approach, standards or specific governance. Indeed, trying to do so will take the market years of work fraught with compromises distracting from the real innovation that is sought after. We believe that different approaches to the development of standards of communication between the different PSPs in the market should be allowed to develop such as:
• National communities developing single interfaces;
• Subgroups of ASPSPs developing solutions;
• Other service providers developing bundled access solutions to groups of ASPSPs (see also our general comment).
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?
There are many different initiatives currently under development (i.e. Electronic Banking Internet Communication Standards, SEPA mail, OAuth2.0 or ÉTS).The EACB considers that market forces and the interactions of supply and demand in the market should drive the development of these solutions. The RTS should not prescribe specific standards.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 difficult to answer this question as there are no other innovative business solutions known. In the present environment though we believe that the issuing of own credentials can only be made by the ASPSP, otherwise the user would have to register at two places in future.As for the design and the maintenance of the common and open standards, we would consider that any interface used should be based on open standards. However we would warn against the establishment of procedurally heavy EU wide governance mechanisms at this stage. We believe that the market should be allowed to develop based on a limited number of communication standards through clusters of ASPSP and TPPs – as described in our general comments and under question 16) with the potential involvement of aggregators.