Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
RBS would, however, like to emphasise a number of points.
**Risks of over use of Strong Authentication**
While we agree (as per Recital 1) that “payment services offered electronically should be carried out in a secure manner”, and also agree that Strong Customer Authentication (SCA) as defined has an important role, we do not agree with all the provisions of Chapter 1.
We do not agree it is appropriate to use SCA for merely accessing a payment account and have concerns about excessive use in authorising payments.
We are concerned that SCA may be over-used. Arguably, if codes are used constantly and for routine events like logging in, this increases the likelihood of new social engineering opportunities for fraudsters, and customers will be desensitised to the use and importance of SCA codes.
For example, if Possession (Security Device) is used at log-in a fraudster may exploit this step to fool the user into authorising a fraudulent transaction using a script such as:
“Your credentials have expired – you will receive a test authorisation message for £xx,xxx to account ending yyy – please use your security device to approve this to complete the log-in process”.
In these circumstances, the user is less likely to spot a fraud if they routinely make use of Possession (Security Device) without specific payment details at log-in.
On the other hand, restricting the use of SCA to higher risk activities - such as authorising payments - makes customers less susceptible to malware and similar social engineering attacks. This is especially so if PSPs educate customers that they will only ever be asked for a code if they need to authorise a payment; any other request may be regarded as fraudulent.
Other concerns include:
• The use of SCA at log-in will potentially add friction to the user-experience and make the PSP’s services less accessible (i.e. users cannot log-in if they don’t happen to have cards / readers / tokens etc. on their person). This may actually deter certain customers from using secure services, the exact opposite of what PSD2 is trying to achieve.
• Costs of complying with this requirement could be considerable, including issuance of additional cards / readers / tokens (e.g. at present, in many corporate PSUs, staff in non-payment authorisation roles do not need a card to view balances and transactions), re-engineering of the roles and privileges model and other application logic changes.
o Furthermore, from a Corporate PSU perspective, the cost of compliance could divert investment away from more innovative security solutions which address issues unique to the Corporate Banking sector (e.g. scams such as invoice diversion fraud and executive impersonation fraud).
• Whilst we agree with use of SCA for remote card payments, applying SCA to all remote card transactions over 10 EUR will significantly affect the current risk based authentication model used for remote card payments and disrupt customers making low risk transactions. This could potentially push them towards less secure payment channels, such as Telephone Orders.
• When applied to cards transactions, considerable reworking of cards online processes will be required.
**What May be Considered Strong Authentication in the Future**
With regards to what may be considered Inherence (Article 5 and Section 3.2.1, paragraph 14 of the Rationale), RBS is concerned that the requirements should be sufficiently generic to allow for technological developments in the future. For example, while we believe that biometric behavioural profiling offers a useful risk indication only at present, it may be that in the future it will be sufficiently robust to provide an Inherence factor. Whilst we do not believe it has reached this level of maturity at this stage, the RTS needs to be sufficiently generic to accommodate technology change in the future.
**Corporate PSUs**
The focus throughout the RTS on consumer payments means that the following business scenarios are not sufficiently catered for by the draft technical standards:
o Authorising a file of imported payments;
o Bulk authorisation of multiple single payments in one request;
o Bulk authorising multiple single international payments involving different currencies or third party usage of customer’s payment instrument; and
o Usage of single-use payment instruments.
The text in Article 2.4 does not sufficiently cover the above scenarios.
Some corporates also experience greater complexity when the payments being batch authorised are across multiple currencies. Whilst an authorisation code could be linked to the payments that have been authorised (for audit / non-repudiation purposes), the display of the amounts and payees details “collectively” does not appear practical against the current wording of Article 2.4.
Like Payments UK, we understand that dynamic linking is proposed to be used for remote credit transfers (including those initiated via a PISP) and card payments. We are uncertain as to what “neutrality” means in this context, but we agree that the RTS should remain neutral with the ASPSP having the option to define their own procedure in relation to when dynamic linking should take place. Segregation of the channel through which the linking connection is made visible to the payer, but on the same device as the payment is made, seems a sensible approach. However:
• Article 2.2(b) restricts the possible solutions that could be used, such as Card/Reader SCA solutions, which do not display payment related information to the payer with the amount and payee. We would welcome more EBA guidance on how dynamic linking should work. But in our view, we would expect that where a credit transfer is made via an online banking service, it would be most practical to show the amount and payee through online banking while codes are shown through a separate device.
• For mobile apps that are combined with the use of risk based profiling, we do not believe that a separate device is required.
In relation to Article 3, RBS is concerned that some of the proposals may themselves introduce new risks. The implication is that PINs should be changed regularly even though the PIN is still known to the PSU. This could cause inconvenience and failed transactions if PINs are forgotten more often. We do not believe that this is necessary as we are not aware of evidence to suggest not changing PINs for use with cards is a serious security risk.
We also have concerns about the interpretation of “non-repeatable” characters. If taken literally, this would seem to suggest that PSUs should not use the same character more than once in a password. Ruling out such a possibility could in itself represent a hint to fraudsters.
We are not clear if this provision means that the same character must not appear twice or more together; we are not convinced this is necessary. If so, then should the requirement also prevent sequential characters such as 123 or ABC, which may be a greater problem? We would welcome examples of knowledge elements that meet the proposed list of security criteria.
Article 3.2 looks for mitigations to prevent disclosure to unauthorised parties .This is straightforward from the PSP perspective, however it is impossible to “guarantee” resistance against unauthorised disclosure of “knowledge”. For example, preventing customers from writing things down or disclosing their details either deliberately, through social engineering (e.g. scams) or coercion. The RTS should acknowledge that this risk would be outside the PSP’s control. Mitigation may come through customer security education and awareness campaigns.
The threat of repudiation of a transaction (that a customer denies they were responsible for a transaction) is also not addressed.
**Risk Profiling of Payments**
In particular RBS would stress that we disagree with the EBA’s rationale for no exemption being made to allow for Risk Based Strong Customer Authentication, as described in paragraphs 52 and 53 of the RTS Background and Rationale, leading to paragraph 54 where the EBA draft concludes “not to propose exemptions based on a transaction-risk analysis performed by the PSP”. We believe that the proposed SCA requirement runs counter to PSD2 and the EBA’s stated policy objectives to ensure “an appropriate level of security for PSUs and PSPs, through the adoption of effective and risk-based requirements” (Rationale 3.a) and “allowing for the development of user-friendly, accessible and innovative means of payment” (Rationale 3.e).
RBS and the wider Payments Industry invest in and use sophisticated and intelligent fraud profiling systems/tools and are strategically moving towards risk based authentication for both remote card payments and online payments. The proposed RTS does not allow for flexibility or innovation. This requirement will negatively impact the customer experience in these channels. Experience has shown that risk profiling is an effective means of preventing fraud. By forcing over-reliance on SCA, the risk of fraud is likely to be increased.
We would urge the EBA to reconsider its position. We suggest that other approaches such as risk based approaches may be used as an exception to SCA. Examples of criteria in such risk based systems are:
*User and Device Information*:
• User behaviour/profiling
• Device ID (genuine customers use the same device time and time again, this allows a lower score to be given as this is a trusted device. If the device changes for that customer the score would reflect this.
• Browser – Much like the above.
• Device type (Iphone/Ipad/Android/PC) – same as above
• Geo location – IP address/IP_Routingtype/region
*Transaction information*:
• Payee PSU type
• Payee PSU name
• Payee PSU location
• Transaction amount
• Payee PSU URL
Such risk based processes must incorporate a mechanism so that where the criteria are not met, SCA is invoked instead. PSPs must satisfy themselves on a frequent basis that their risk profiling framework is effective.
Such an approach may be used provided that PSPs are able to evidence to the competent authority that they are monitoring and regularly adjusting their Risk Based Model to manage fraud risk.
Alternatively, a fixed value threshold might be used to force the default to SCA. While this would be straightforward to include in the RTS and enforce, we do not believe it would be successful in practice. This is because an appropriate value limit would vary considerably from paying PSU to paying PSU, from payee PSU to payee PSU, etc. and would undermine the benefit of this sophisticated system. No one size fits all.
However, if the EBA was minded to take this route we would suggest a high threshold (measured in thousands of euro) where SCA always has to be used with a duty on the PSP to revert to SCA in circumstances where the risk profiling suggested a transaction was risky.
**Other Comments**
RBS does not agree with needing SCA for online accounts that have not used SCA in the last month, as some customers do not make payments, but check their bank accounts via online or mobile banking monthly. Nor does this work well for a mobile banking service. It also drives an inconsistent access model, making customer education much more difficult.
RBS also disagrees with an exemption based on monetary values i.e. under 10 EUR and up to 100 EUR cumulative. This is far too low and simply because a payment is less than 10 EUR does not necessarily indicate low risk. Again, we strongly support making informed SCA decisions on a risk based approach. Also any limits that are published are likely to be exploited by criminals and therefore offer little protection to customers. There may be merit in the delegation of limit setting to the national competent authority in order to facilitate limits appropriate to the local market.
RBS does not agree that proximity payments, such as contactless POS or mobile card based NFC solutions, should be in scope of the RTS. These are “card present transactions” and therefore considered out of scope of the remote electronic payments definition and would therefore welcome this clarity being included in the RTS. Also, having firm limits means that the RTS is not future proofed against further contactless based innovations.
Additionally, the exemptions are heavily consumer focussed and do not represent business / corporate scenarios. For example many corporate on-line banking solutions require SCA on ALL external payments (apart from inter account transfers) – and therefore SCA should be exempt at the log-in stage. The lack of support for risk based approaches amplifies this shortfall. To cover all the required exemption scenarios across personal / business / corporate sectors would result in a very long final document.
It is also worth noting that corporate customer processes usually feature additional controls not covered by the RTS, such as separation of duties and dual authorisation of payments which reduce the need for SCA in some circumstances.
Furthermore, turning to corporate use of cards, we believe that the risks associated with these payment instruments are much lower than in the personal sector, as they are managed on a company level and therefore should be considered under the exception list for SCA.
Finally, RBS is concerned that, as written, the RTS might require that Chip & PIN cannot be used for all transactions at ATMs if physical transactions are in scope and exceptions to SCA are mandatory. We are sure this is not intended, but suggest clarification.
If the exemption option was provided to a PISP or AISP then a chain of liability is created which makes the process more complex. We do, however, recognise that there would need to be some form of control to prevent the ASPSP applying SCA in a discriminatory manner to gain benefit for itself or another PSP. Therefore, the RTS should make it clear that the final SCA decision always sits with the ASPSP not the PISP/AISP, despite the exemptions.
There is likely to already be a high level of compliance in the cards industry due to the apparent overlap with existing PCI DSS standards.
RBS welcomes the EBA’s statement in Article 19.1 that ASPSPs should “offer at least one communication interface”. RBS advocates that the industry, widely drawn, should be encouraged to agree on a standard API method to facilitate such communication. This will enable greatest ease of access to the market with minimum cost to all parties.
Regarding Article 17.1, we understand that bilateral identification is workable when the payer’s device is “intelligent”. However, if the device is a Personal Computer, it is not clear how the PSP would otherwise be able to identify without having some sort of certificate on the user’s device. It is also impractical for the PSP to hold this data given that each customer could use multi-devices. Therefore we do not support 17.1 at a customer level and do not believe it is required where SCA is used.
We would emphasise that the use of certificates to identify PSP to PSP seems sensible, although it would not be appropriate for consumers and many businesses, due to cost and complexity. As to the use of e-IDAS compliant certificates, we support the need for a standard, but note that it will require the emergence of a number of e-IDAS compliant trust service providers to become a practical requirement. At the moment we are not aware that these are widely available.
Critically in terms of identification, RBS would urge that any member state and Europe-wide registers of PISPs and AISPs are easily accessible and updated on a real time basis as circumstances of firms change. Only PISPs/AISPs registered with the relevant authority should be eligible to obtain certificates (whether e-IDAS or any other).
• We do not see the benefit in having specific counts for all customer/AIS entries as this does not adequately protect against Denial of Service risks and would introduce significant tracking requirements.
• The proposed limit of twice per day will potentially limit propositional elements of the PSD2 legislation, which we believe would be contrary to the competition objectives of the Directive. Whilst having a limit is essential to stop spurious activity and potential to create DDOS issues, only having information every 12 hours would mean that AISPs would not be able to provide first response solutions and real time notifications and warnings to customers.
We therefore recommend that the EBA consider:
• A requirement for “rate limiting” AISP requests rather than specify a specific number per day. This will ensure that access requests, not directly linked to a PSU’s request, are relative to the size of the AISP, and the ASPSP can flexibly manage volumes and protect availability of service.
There is a need for ASPSPs to be able to differentiate API calls that are driven by actual end-customer activity (i.e. a user accessing their banking app) and API calls that are driven by the service providers operating the service in background.
Question 1: Do you agree with the EBA’s reasoning on the requirements of the strong customer authentication, and the resultant provisions proposed in Chapter 1 of the draft RTS?
RBS notes and supports the detailed response provided by Payments UK to which we have contributed.RBS would, however, like to emphasise a number of points.
**Risks of over use of Strong Authentication**
While we agree (as per Recital 1) that “payment services offered electronically should be carried out in a secure manner”, and also agree that Strong Customer Authentication (SCA) as defined has an important role, we do not agree with all the provisions of Chapter 1.
We do not agree it is appropriate to use SCA for merely accessing a payment account and have concerns about excessive use in authorising payments.
We are concerned that SCA may be over-used. Arguably, if codes are used constantly and for routine events like logging in, this increases the likelihood of new social engineering opportunities for fraudsters, and customers will be desensitised to the use and importance of SCA codes.
For example, if Possession (Security Device) is used at log-in a fraudster may exploit this step to fool the user into authorising a fraudulent transaction using a script such as:
“Your credentials have expired – you will receive a test authorisation message for £xx,xxx to account ending yyy – please use your security device to approve this to complete the log-in process”.
In these circumstances, the user is less likely to spot a fraud if they routinely make use of Possession (Security Device) without specific payment details at log-in.
On the other hand, restricting the use of SCA to higher risk activities - such as authorising payments - makes customers less susceptible to malware and similar social engineering attacks. This is especially so if PSPs educate customers that they will only ever be asked for a code if they need to authorise a payment; any other request may be regarded as fraudulent.
Other concerns include:
• The use of SCA at log-in will potentially add friction to the user-experience and make the PSP’s services less accessible (i.e. users cannot log-in if they don’t happen to have cards / readers / tokens etc. on their person). This may actually deter certain customers from using secure services, the exact opposite of what PSD2 is trying to achieve.
• Costs of complying with this requirement could be considerable, including issuance of additional cards / readers / tokens (e.g. at present, in many corporate PSUs, staff in non-payment authorisation roles do not need a card to view balances and transactions), re-engineering of the roles and privileges model and other application logic changes.
o Furthermore, from a Corporate PSU perspective, the cost of compliance could divert investment away from more innovative security solutions which address issues unique to the Corporate Banking sector (e.g. scams such as invoice diversion fraud and executive impersonation fraud).
• Whilst we agree with use of SCA for remote card payments, applying SCA to all remote card transactions over 10 EUR will significantly affect the current risk based authentication model used for remote card payments and disrupt customers making low risk transactions. This could potentially push them towards less secure payment channels, such as Telephone Orders.
• When applied to cards transactions, considerable reworking of cards online processes will be required.
**What May be Considered Strong Authentication in the Future**
With regards to what may be considered Inherence (Article 5 and Section 3.2.1, paragraph 14 of the Rationale), RBS is concerned that the requirements should be sufficiently generic to allow for technological developments in the future. For example, while we believe that biometric behavioural profiling offers a useful risk indication only at present, it may be that in the future it will be sufficiently robust to provide an Inherence factor. Whilst we do not believe it has reached this level of maturity at this stage, the RTS needs to be sufficiently generic to accommodate technology change in the future.
**Corporate PSUs**
The focus throughout the RTS on consumer payments means that the following business scenarios are not sufficiently catered for by the draft technical standards:
o Authorising a file of imported payments;
o Bulk authorisation of multiple single payments in one request;
o Bulk authorising multiple single international payments involving different currencies or third party usage of customer’s payment instrument; and
o Usage of single-use payment instruments.
The text in Article 2.4 does not sufficiently cover the above scenarios.
Some corporates also experience greater complexity when the payments being batch authorised are across multiple currencies. Whilst an authorisation code could be linked to the payments that have been authorised (for audit / non-repudiation purposes), the display of the amounts and payees details “collectively” does not appear practical against the current wording of Article 2.4.
Question 2: In particular, in relation to the “dynamic linking” procedure, do you agree with the EBA’s reasoning that the requirements should remain neutral as to when the “dynamic linking” should take place, under the conditions that the channel, mobile application, or device where the information about the amount and the payee of the transaction is displayed is independent or segregated from the channel, mobile application or device used for initiating the payment, as foreseen in Article 2.2 of the draft RTS.
RBS supports the comments of Payments UK.Like Payments UK, we understand that dynamic linking is proposed to be used for remote credit transfers (including those initiated via a PISP) and card payments. We are uncertain as to what “neutrality” means in this context, but we agree that the RTS should remain neutral with the ASPSP having the option to define their own procedure in relation to when dynamic linking should take place. Segregation of the channel through which the linking connection is made visible to the payer, but on the same device as the payment is made, seems a sensible approach. However:
• Article 2.2(b) restricts the possible solutions that could be used, such as Card/Reader SCA solutions, which do not display payment related information to the payer with the amount and payee. We would welcome more EBA guidance on how dynamic linking should work. But in our view, we would expect that where a credit transfer is made via an online banking service, it would be most practical to show the amount and payee through online banking while codes are shown through a separate device.
• For mobile apps that are combined with the use of risk based profiling, we do not believe that a separate device is required.
Question 3: In particular, in relation to the protection of authentication elements, are you aware of other threats than the ones identified in articles 3, 4 and 5 of the draft RTS against which authentication elements should be resistant?
RBS supports the comments of Payments UK.In relation to Article 3, RBS is concerned that some of the proposals may themselves introduce new risks. The implication is that PINs should be changed regularly even though the PIN is still known to the PSU. This could cause inconvenience and failed transactions if PINs are forgotten more often. We do not believe that this is necessary as we are not aware of evidence to suggest not changing PINs for use with cards is a serious security risk.
We also have concerns about the interpretation of “non-repeatable” characters. If taken literally, this would seem to suggest that PSUs should not use the same character more than once in a password. Ruling out such a possibility could in itself represent a hint to fraudsters.
We are not clear if this provision means that the same character must not appear twice or more together; we are not convinced this is necessary. If so, then should the requirement also prevent sequential characters such as 123 or ABC, which may be a greater problem? We would welcome examples of knowledge elements that meet the proposed list of security criteria.
Article 3.2 looks for mitigations to prevent disclosure to unauthorised parties .This is straightforward from the PSP perspective, however it is impossible to “guarantee” resistance against unauthorised disclosure of “knowledge”. For example, preventing customers from writing things down or disclosing their details either deliberately, through social engineering (e.g. scams) or coercion. The RTS should acknowledge that this risk would be outside the PSP’s control. Mitigation may come through customer security education and awareness campaigns.
The threat of repudiation of a transaction (that a customer denies they were responsible for a transaction) is also not addressed.
Question 4: Do you agree with the EBA’s reasoning on the exemptions from the application of Article 97 on strong customer authentication and on security measures, and the resultant provisions proposed in Chapter 2 of the draft RTS?
RBS supports the views expressed by Payments UK and stresses the following points.**Risk Profiling of Payments**
In particular RBS would stress that we disagree with the EBA’s rationale for no exemption being made to allow for Risk Based Strong Customer Authentication, as described in paragraphs 52 and 53 of the RTS Background and Rationale, leading to paragraph 54 where the EBA draft concludes “not to propose exemptions based on a transaction-risk analysis performed by the PSP”. We believe that the proposed SCA requirement runs counter to PSD2 and the EBA’s stated policy objectives to ensure “an appropriate level of security for PSUs and PSPs, through the adoption of effective and risk-based requirements” (Rationale 3.a) and “allowing for the development of user-friendly, accessible and innovative means of payment” (Rationale 3.e).
RBS and the wider Payments Industry invest in and use sophisticated and intelligent fraud profiling systems/tools and are strategically moving towards risk based authentication for both remote card payments and online payments. The proposed RTS does not allow for flexibility or innovation. This requirement will negatively impact the customer experience in these channels. Experience has shown that risk profiling is an effective means of preventing fraud. By forcing over-reliance on SCA, the risk of fraud is likely to be increased.
We would urge the EBA to reconsider its position. We suggest that other approaches such as risk based approaches may be used as an exception to SCA. Examples of criteria in such risk based systems are:
*User and Device Information*:
• User behaviour/profiling
• Device ID (genuine customers use the same device time and time again, this allows a lower score to be given as this is a trusted device. If the device changes for that customer the score would reflect this.
• Browser – Much like the above.
• Device type (Iphone/Ipad/Android/PC) – same as above
• Geo location – IP address/IP_Routingtype/region
*Transaction information*:
• Payee PSU type
• Payee PSU name
• Payee PSU location
• Transaction amount
• Payee PSU URL
Such risk based processes must incorporate a mechanism so that where the criteria are not met, SCA is invoked instead. PSPs must satisfy themselves on a frequent basis that their risk profiling framework is effective.
Such an approach may be used provided that PSPs are able to evidence to the competent authority that they are monitoring and regularly adjusting their Risk Based Model to manage fraud risk.
Alternatively, a fixed value threshold might be used to force the default to SCA. While this would be straightforward to include in the RTS and enforce, we do not believe it would be successful in practice. This is because an appropriate value limit would vary considerably from paying PSU to paying PSU, from payee PSU to payee PSU, etc. and would undermine the benefit of this sophisticated system. No one size fits all.
However, if the EBA was minded to take this route we would suggest a high threshold (measured in thousands of euro) where SCA always has to be used with a duty on the PSP to revert to SCA in circumstances where the risk profiling suggested a transaction was risky.
**Other Comments**
RBS does not agree with needing SCA for online accounts that have not used SCA in the last month, as some customers do not make payments, but check their bank accounts via online or mobile banking monthly. Nor does this work well for a mobile banking service. It also drives an inconsistent access model, making customer education much more difficult.
RBS also disagrees with an exemption based on monetary values i.e. under 10 EUR and up to 100 EUR cumulative. This is far too low and simply because a payment is less than 10 EUR does not necessarily indicate low risk. Again, we strongly support making informed SCA decisions on a risk based approach. Also any limits that are published are likely to be exploited by criminals and therefore offer little protection to customers. There may be merit in the delegation of limit setting to the national competent authority in order to facilitate limits appropriate to the local market.
RBS does not agree that proximity payments, such as contactless POS or mobile card based NFC solutions, should be in scope of the RTS. These are “card present transactions” and therefore considered out of scope of the remote electronic payments definition and would therefore welcome this clarity being included in the RTS. Also, having firm limits means that the RTS is not future proofed against further contactless based innovations.
Additionally, the exemptions are heavily consumer focussed and do not represent business / corporate scenarios. For example many corporate on-line banking solutions require SCA on ALL external payments (apart from inter account transfers) – and therefore SCA should be exempt at the log-in stage. The lack of support for risk based approaches amplifies this shortfall. To cover all the required exemption scenarios across personal / business / corporate sectors would result in a very long final document.
It is also worth noting that corporate customer processes usually feature additional controls not covered by the RTS, such as separation of duties and dual authorisation of payments which reduce the need for SCA in some circumstances.
Furthermore, turning to corporate use of cards, we believe that the risks associated with these payment instruments are much lower than in the personal sector, as they are managed on a company level and therefore should be considered under the exception list for SCA.
Finally, RBS is concerned that, as written, the RTS might require that Chip & PIN cannot be used for all transactions at ATMs if physical transactions are in scope and exceptions to SCA are mandatory. We are sure this is not intended, but suggest clarification.
Question 5: Do you have any concern with the list of exemptions contained in Chapter 2 of the draft RTS for the scenario that PSPs are prevented from implementing SCA on transactions that meet the criteria for exemption?
We do not agree that PSPs should be prevented from using SCA on transactions that meet the criteria for exemption; as drafted the exemptions in Article 8 appear to be compulsory. The option to take advantage of the permitted exemptions should be at the discretion of the PSP who “owns” the customer and the SCA process. Control will ensure that PSPs can use SCA and protect the customer if they deem the payment as higher risk. This way any liability to the payer as a result of the exemption lies with the PSP and therefore no disputes are likely between different parties.If the exemption option was provided to a PISP or AISP then a chain of liability is created which makes the process more complex. We do, however, recognise that there would need to be some form of control to prevent the ASPSP applying SCA in a discriminatory manner to gain benefit for itself or another PSP. Therefore, the RTS should make it clear that the final SCA decision always sits with the ASPSP not the PISP/AISP, despite the exemptions.
Question 6: Do you agree with the EBA’s reasoning on the protection of the confidentiality and the integrity of the payment service users’ personalised security credentials, and the resultant provisions proposed in Chapter 3 of the draft RTS?
RBS supports the points made by Payments UK. In general the provisions of chapter 3 are appropriate, but guidance is needed on what a secure method is in terms of sending out PINs and cards. Today these are sent separately in the post.There is likely to already be a high level of compliance in the cards industry due to the apparent overlap with existing PCI DSS standards.
Question 7: Do you agree with the EBA’s reasoning on the requirements for common and secure open standards of communication for the purpose of identification, authentication, notification, and information, and the resultant provisions proposed in Chapter 4 of the draft RTS?
RBS supports Payments UK’s comments, in particular on the importance of standards.RBS welcomes the EBA’s statement in Article 19.1 that ASPSPs should “offer at least one communication interface”. RBS advocates that the industry, widely drawn, should be encouraged to agree on a standard API method to facilitate such communication. This will enable greatest ease of access to the market with minimum cost to all parties.
Regarding Article 17.1, we understand that bilateral identification is workable when the payer’s device is “intelligent”. However, if the device is a Personal Computer, it is not clear how the PSP would otherwise be able to identify without having some sort of certificate on the user’s device. It is also impractical for the PSP to hold this data given that each customer could use multi-devices. Therefore we do not support 17.1 at a customer level and do not believe it is required where SCA is used.
Question 8: In particular, do you agree that the use of ISO 20022 elements, components or approved message definitions, if available, should be required to ensure the interoperability of different technological communication solutions implemented between PSPs for the provision of AIS, PIS or for the confirmation on the availability of funds? Do you see any particular technical constraint that would prevent the use of such industry standards?
RBS supports Payments UK’s comments and use of ISO20022.Question 9: With regards to identification between PSPs, do you agree that website certificates issued by a qualified trust service provider under an e-IDAS policy would be suitable and allow for the use of all common types of devices (such as computers, tablets and mobile phones) for carrying out different payment services ?
RBS supports the comments of Payments UK.We would emphasise that the use of certificates to identify PSP to PSP seems sensible, although it would not be appropriate for consumers and many businesses, due to cost and complexity. As to the use of e-IDAS compliant certificates, we support the need for a standard, but note that it will require the emergence of a number of e-IDAS compliant trust service providers to become a practical requirement. At the moment we are not aware that these are widely available.
Critically in terms of identification, RBS would urge that any member state and Europe-wide registers of PISPs and AISPs are easily accessible and updated on a real time basis as circumstances of firms change. Only PISPs/AISPs registered with the relevant authority should be eligible to obtain certificates (whether e-IDAS or any other).
Question 10: With regards to the frequency with which AIS providers can request information from designated payment accounts when the payment service user is not actively requesting such information, do you agree that the proposed limit of no more than two times a day achieve an appropriate balance between allowing AISP to provide updated information to their users while not negatively impacting the availability of the ASPSP’s communication interface? If not, please indicate what would be in your view the appropriate frequency and rationale for such frequency.
RBS supports some limitation on AIS providers’ access to limit DDOS attacks and manage capacity efficiently; we are not convinced that twice per day is the appropriate level because:• We do not see the benefit in having specific counts for all customer/AIS entries as this does not adequately protect against Denial of Service risks and would introduce significant tracking requirements.
• The proposed limit of twice per day will potentially limit propositional elements of the PSD2 legislation, which we believe would be contrary to the competition objectives of the Directive. Whilst having a limit is essential to stop spurious activity and potential to create DDOS issues, only having information every 12 hours would mean that AISPs would not be able to provide first response solutions and real time notifications and warnings to customers.
We therefore recommend that the EBA consider:
• A requirement for “rate limiting” AISP requests rather than specify a specific number per day. This will ensure that access requests, not directly linked to a PSU’s request, are relative to the size of the AISP, and the ASPSP can flexibly manage volumes and protect availability of service.
There is a need for ASPSPs to be able to differentiate API calls that are driven by actual end-customer activity (i.e. a user accessing their banking app) and API calls that are driven by the service providers operating the service in background.