Response to discussion on RTS on strong customer authentication and secure communication under PSD2
Go back
This risk is substantially reduced for read-only financial data - where no payment can be authorised the risk is one of privacy rather than fraud. This is an important point as we reflect on the fact that read-only financial data is low-risk in comparison to write-access. The devising of authentication and security measures should account for this.
With respect to specific examples of where impersonation may cause a problem, the likelihood is that these would involve changes of address or other profile data; applying for new products or altering existing products such as overdrafts; adding additional cardholders; or setting up or cancelling Direct Debits and other regular payments.
We need to ensure a system is in place where customers can be notified of such a data breach.
Our presumption would be that the first connection should be subject to strong tokenised authentication between the TPP and the bank, but that ongoing connections need not require re-authentication. To use an analogy, getting through the front door should require strong authentication, but once a user is in the house they should be able to move freely.
Our key suggestion here, though, is that the authentication requirements must be proportional to the risk, with read-only data access being relatively low-risk.
1. Biometric (fingerprint, retina, DNA)
2. Attributed (something that belongs, like name, address, social ID)
3. Official (passport, driving licence, banks account details)
4. Behavioural (likes, hobbies, activity, personality)
We do believe inherence elements have a role to play in authentication, particularly as technology advances. Various services are now being created which link Attributed and Official Data to the softer elements of Behavioural, which can not only help to validate the identity was provide some insight into the likely behaviour of a customer
Whilst they may arguably not be appropriate at this stage for the first connection, elements such as touch ID are already used to good effect as an alternative to continual customer re-authentication, for example in Apple Pay and in other finance apps.
Linking inferences and behaviours such as psychographic individual profiles with elements of official data, for example, strengthens the level of authentication. An individual’s behaviour is often more recent than “stored” historical data and certainly more difficult to fake. Linking patterns of who, where, when and how services such as payments are linked (in real time) delivers a strengthened identity. This can all be achieved anonymously with no exchange or “real identifiable personal” information.
Some innovative identity firms are operating In financial services, where a transaction requires both an identity and a future risk or capability element and where personality has a strong inference on ability to maintain payments. Whilst this will require financial regulatory changes for adoption it is clear to improving lending and financial capability models that behaviour could have an important role to play.
We must remember that TPPs exist to satisfy customer demand for aggregation and payments. If the process of using a TPP became laborious due to unnecessary re-authentication then the impact and usage of these services would be severely limited.
It remains crucial, however, to keep the customer experience in the forefront of our minds. Our members’ customers are discerning, and they require seamless ease of use, as well as strong security, to be minded to use the services. That is why establishing strong authentication for first use only, and distinguishing between the risk attached to read-only and write access, is vital.
It is also important to consider fraud detection and payment method guarantees (e.g. the UK Direct Debit guarantee). With appropriate levels of fraud detection, banks could only require dynamically linked strong authentication for transactions that trigger a fraud flag. This is analogous to Web Application Firewalls which present “captchas” to suspicious traffic, but let safe traffic through.
We would re-iterate that access for an AIS provider should only require strong customer authentication at the first connection - it would be detrimental to the consumer experience for it to be required on an ongoing basis.
Additionally, it is important to ensure that PIS providers whose services do not fall into an exemption are not required to go through a process of authentication which is so burdensome that customers will simply revert to online banking with a single institution.
Authorisation frameworks such as OAuth 2 allow for a consumer to authorise a third party without the third party having any knowledge of the user’s credentials. We also suggest that authentication is not handled via any central authority, but rather is “point to point”. Central systems such as “bank id” in Sweden and NemID in Norway, while seemingly efficient, bring the following problems:
1. They are very difficult to keep up-to-date, which is necessary from both a security and user experience perspective
2. They open up users to individual “denial of service’ attacks. For example if the same login system is used for multiple services, an attacker can potentially cause significant harm by causing a user’s account to be locked.
3. They limit competition as companies cannot compete on the ease of use of their authentication, everyone is restricted to the lowest common denominator.
Lessons should be learnt from the HBCI standard in Germany, where point to point access was available, but the lack of a common API data and authentication standard meant that the benefits to innovation and competition that were intended did not materialise.
As an industry we welcome regulation - we think it imperative in order to ensure consumer confidence in our products. However, this must be mixed with an assurance that the consumer experience (specifically the authentication process) is smooth.
Similarly, we would welcome guidance from the EBA on the issue of screen scraping. As an industry we are keen to move towards an API framework which would mean that credentials would not need to be shared, however until such a framework is in place covering all banks and all data then screen scraping will continue.
We think it is important to clarify that it is not the job of a bank to perform any form of audit function once a TPP has been approved onto the register by the CA. Instead, that would be the job of any organisation mandated to do so by the CA, which could include an industry body such as FDATA.
Secondly, it is important to remember that screen-scraping involves the insertion of personalised security credentials and is carried out by several of our members to extremely high security standards. As previously noted we would welcome EBA clarification on its vision of the future of screen-scraping.
There are several issues which could degrade this customer journey, including redacted data and continual re-authentication, and as the customer journey becomes more difficult so the TPP services become less attractive.
We encourage the EBA to take this on board and as a result to manage different risks appropriately, with read-only transaction data classed as low-risk.
We support the EBA working to ensure that there is no divergence in standards between payment services and electronic identity. However we suggest that the EBA focus on the technical standards that could enable multiple parties to be “identity providers” rather than recommending a single pan-european identity provider.
An example from a different sector is Google. Many companies use the Google’s OpenID Connect API to support identity and/or account access.
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.
The primary risk of third-party write access data, in common with the primary risk of online banking in general, is that of impersonation. In other words, if a malign individual is able to access another individual’s login credentials then there is a clear risk of fraud.This risk is substantially reduced for read-only financial data - where no payment can be authorised the risk is one of privacy rather than fraud. This is an important point as we reflect on the fact that read-only financial data is low-risk in comparison to write-access. The devising of authentication and security measures should account for this.
With respect to specific examples of where impersonation may cause a problem, the likelihood is that these would involve changes of address or other profile data; applying for new products or altering existing products such as overdrafts; adding additional cardholders; or setting up or cancelling Direct Debits and other regular payments.
We need to ensure a system is in place where customers can be notified of such a data breach.
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?
We would highlight various examples of possession elements, both physical and digital, including smartphones, chip-and-pin card devices, and physical and software-based key generators. However we would suggest that there should be a distinction between possession elements which are very closely linked to the PSU (for an example a smartphone) and those which are less personal (for example a PC on a network).Our presumption would be that the first connection should be subject to strong tokenised authentication between the TPP and the bank, but that ongoing connections need not require re-authentication. To use an analogy, getting through the front door should require strong authentication, but once a user is in the house they should be able to move freely.
Our key suggestion here, though, is that the authentication requirements must be proportional to the risk, with read-only data access being relatively low-risk.
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?
There are 4 ‘pillars’ of identity:1. Biometric (fingerprint, retina, DNA)
2. Attributed (something that belongs, like name, address, social ID)
3. Official (passport, driving licence, banks account details)
4. Behavioural (likes, hobbies, activity, personality)
We do believe inherence elements have a role to play in authentication, particularly as technology advances. Various services are now being created which link Attributed and Official Data to the softer elements of Behavioural, which can not only help to validate the identity was provide some insight into the likely behaviour of a customer
Whilst they may arguably not be appropriate at this stage for the first connection, elements such as touch ID are already used to good effect as an alternative to continual customer re-authentication, for example in Apple Pay and in other finance apps.
Linking inferences and behaviours such as psychographic individual profiles with elements of official data, for example, strengthens the level of authentication. An individual’s behaviour is often more recent than “stored” historical data and certainly more difficult to fake. Linking patterns of who, where, when and how services such as payments are linked (in real time) delivers a strengthened identity. This can all be achieved anonymously with no exchange or “real identifiable personal” information.
Some innovative identity firms are operating In financial services, where a transaction requires both an identity and a future risk or capability element and where personality has a strong inference on ability to maintain payments. Whilst this will require financial regulatory changes for adoption it is clear to improving lending and financial capability models that behaviour could have an important role to play.
We must remember that TPPs exist to satisfy customer demand for aggregation and payments. If the process of using a TPP became laborious due to unnecessary re-authentication then the impact and usage of these services would be severely limited.
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)?
We agree with the point 32 - possession elements such as a phone or physical key generator that do not also include a knowledge or inherence element are insecure. So, the security framework should be designed such that the loss of a phone or other physical device does not result in the compromise of a payment account.It remains crucial, however, to keep the customer experience in the forefront of our minds. Our members’ customers are discerning, and they require seamless ease of use, as well as strong security, to be minded to use the services. That is why establishing strong authentication for first use only, and distinguishing between the risk attached to read-only and write access, is vital.
5. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to dynamic linking?
We agree with point 35. Requiring dynamic linking limits the potential authentication channels. It is again worth remembering that different levels of risk, and therefore security, should be applied to different levels of access. So it makes little sense for an AIS requiring read-only access to be classed in the same risk category as a PIS requiring write access. In the case of point 35, this type of stronger authentication could be limited just to high value payments or adding new payees, for example.It is also important to consider fraud detection and payment method guarantees (e.g. the UK Direct Debit guarantee). With appropriate levels of fraud detection, banks could only require dynamically linked strong authentication for transactions that trigger a fraud flag. This is analogous to Web Application Firewalls which present “captchas” to suspicious traffic, but let safe traffic through.
6. In your view, which solutions for mobile devices fulfil both the objective of independence and dynamic linking already today?
Whilst we appreciate there may be many, the most obvious example is Apple Pay.7. Do you consider the clarifications suggested regarding the potential exemptions to strong customer authentication, to be useful?
We do consider the clarifications to be useful. Specifically, we would suggest a further clarification with respect to an exemption for ongoing access to read-only data once the first connection has been made, such as: “ongoing access of data by a previously authorised third party”.We would re-iterate that access for an AIS provider should only require strong customer authentication at the first connection - it would be detrimental to the consumer experience for it to be required on an ongoing basis.
Additionally, it is important to ensure that PIS providers whose services do not fall into an exemption are not required to go through a process of authentication which is so burdensome that customers will simply revert to online banking with a single institution.
8. Are there any other factors the EBA should consider when deciding on the exemptions applicable to the forthcoming regulatory technical standards?
The EBA should consider the duration of access. For example, just as ongoing payments to the same payee have been identified as exempt, similar consideration should be made for users who give access to third parties to read their account data. Such access should be able to be authorised indefinitely and revoked in a similar manner to how a regular payment such as a direct debit is stopped. At the very least, you should consider a system of reactive confirmation that the user wishes to keep read-access in place, as opposed to the need for continual pro-active authentication.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?
We support the recommendation that appropriate data is collected in order to perform real time risk assessment. However, we suggest that the EBA refrain from mandating the technical details of how such a risk assessment would be performed. Different providers will have different appetites to risk and they should be permitted to manage this accordingly.10. Do you consider the clarification suggested regarding the protection of users personalised security credentials to be useful?
Yes.11. What other risks with regard to the protection of users’ personalised security credentials do you identify?
We would not identify anything in addition to that which you already have. However we would make several general observations.Authorisation frameworks such as OAuth 2 allow for a consumer to authorise a third party without the third party having any knowledge of the user’s credentials. We also suggest that authentication is not handled via any central authority, but rather is “point to point”. Central systems such as “bank id” in Sweden and NemID in Norway, while seemingly efficient, bring the following problems:
1. They are very difficult to keep up-to-date, which is necessary from both a security and user experience perspective
2. They open up users to individual “denial of service’ attacks. For example if the same login system is used for multiple services, an attacker can potentially cause significant harm by causing a user’s account to be locked.
3. They limit competition as companies cannot compete on the ease of use of their authentication, everyone is restricted to the lowest common denominator.
Lessons should be learnt from the HBCI standard in Germany, where point to point access was available, but the lack of a common API data and authentication standard meant that the benefits to innovation and competition that were intended did not materialise.
As an industry we welcome regulation - we think it imperative in order to ensure consumer confidence in our products. However, this must be mixed with an assurance that the consumer experience (specifically the authentication process) is smooth.
Similarly, we would welcome guidance from the EBA on the issue of screen scraping. As an industry we are keen to move towards an API framework which would mean that credentials would not need to be shared, however until such a framework is in place covering all banks and all data then screen scraping will continue.
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?
We have not, but we would suggest that the EBA limits itself to highlighting risks and current best practices rather than mandating specific solutions.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?
As part of the OBWG report we suggested that the register(s) referenced in PSD2 Article 15 could also perform the role of a Certificate Authority (CA). This would allow companies in real time to cryptographically confirm each other’s identity, as referenced in point 63(b)).We think it is important to clarify that it is not the job of a bank to perform any form of audit function once a TPP has been approved onto the register by the CA. Instead, that would be the job of any organisation mandated to do so by the CA, which could include an industry body such as FDATA.
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?
We view the risk in the payment chain as as user error or fraud resulting in a payments being sent to the wrong place. We do not see a significant risk in terms of confidentiality.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?
We are content with all aspects of paragraph 63 other than aspects of 63(d). Firstly, we are concerned about the wording around ‘sensitive payment data’. We are concerned that this passage may be used to support a case in favour of redacting data, which we emphatically oppose. Data - whether deemed sensitive or otherwise - is owned by the consumer and, having requested that their banks share data with their TPP, the consumer should be permitted to access all of it.Secondly, it is important to remember that screen-scraping involves the insertion of personalised security credentials and is carried out by several of our members to extremely high security standards. As previously noted we would welcome EBA clarification on its vision of the future of screen-scraping.
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?
We would reiterate that the consumer journey should be at the forefront of our minds. Third party data aggregation services exist as a result of consumer demand, and we constantly seek to make that process easier, including through the use of an API.There are several issues which could degrade this customer journey, including redacted data and continual re-authentication, and as the customer journey becomes more difficult so the TPP services become less attractive.
We encourage the EBA to take this on board and as a result to manage different risks appropriately, with read-only transaction data classed as low-risk.
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?
As recommended in the OBWG report, we suggest that OAuth 2 with Open ID Connect are strong standards that support the PSU authenticating with ASPSPs to authorise AIS and PIS providers. We also recommend that TLS v1.2 as the protocol for securing data in transit. In addition we recommend the use of Public Key Infrastructure with Certificate Authorities.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)?
We would suggest that you limit your recommendations to existing standards that are already in use and which are not tied to any specific vendors. A well constructed system would be one which ensures that innovation is not stifled, and in this case that will mean allowing innovation around principle-based security methodology rather than any defined method.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.
We agree that the RTS being developed for PSD2 should take into account e-IDAS regulation and associated use-cases. We suggest that the EBA focus on ensuring that the API standards used for accessing payment accounts take into account electronic identification as a use case (for example payment service providers such as banks could be well placed to provide electronic identification of PSUs). The OAuth / OpenID Connect standard proposed by the Open Banking Working Group has “electronic identification” as its base permission level (or scope).We support the EBA working to ensure that there is no divergence in standards between payment services and electronic identity. However we suggest that the EBA focus on the technical standards that could enable multiple parties to be “identity providers” rather than recommending a single pan-european identity provider.
An example from a different sector is Google. Many companies use the Google’s OpenID Connect API to support identity and/or account access.