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.

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.

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.

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.

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.

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.

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.

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.

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.

We have not, but we would suggest that the EBA limits itself to highlighting risks and current best practices rather than mandating specific solutions.

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.

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.

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.

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.

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.

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.

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.

As discussed in our answer above we suggest that ASPSPs could potentially be “qualified trust services”. We are not sure that the use of a pan-European trust service would address the risks related to confidentiality, integrity and availability.