Response to discussion on RTS on strong customer authentication and secure communication under PSD2
Go back
Sort code and account number is not used to for strong customer identity online but might well be used for identifying where a payment is going to via the TPP. Creating a new mechanism for routing the payment is pointless as these two things are required to route a payment via whatever mechanism underlies the bank transfer (i.e. faster payments, CHAPS, BACS). There is no appetite for a government owned digital identity scheme (and in fact the government is looking to piggyback bank strong customer authentication for their own services in the future).
b. It is clear that any solution should provide a layer of abstraction which hides the underlying account details, for example Pay by Bank app™ (Zapp).
Zapp does hide the account details from the merchant. It leverages the users mobile bank app. The merchant generates a code, via Zapp, that the user puts into his bank app. The bank retrieves the payment details from VocaLink using the code and makes a faster payment, at which point the merchant is informed that it has been paid.
The user experience is as follows: Clicking the Pay by Bank app™ symbol online will automatically open a consumer’s bank app on their phone. Once securely logged in, they can quickly complete their payment. Consumers will be able to see their account balances before they pay and choose different accounts to pay from, thereby staying more in control of their finances.
NB it provides a layer of abstraction like apple pay and others which hides the underlying account details.
c. PayM, for example uses Dynamic Linking to confirm the amount and payee before releasing the payment instruction.
d. MyPINpad, for example is provided for this purpose, to obtain confirmation by a payer that the specific transaction is indeed approved by the payer: i.e. the PIS has not created a spoof transaction.
b. It is no longer adequate to authenticate just the user; best of breed banks authenticate the user, the device and the actual transaction to ensure that none of them are anomalous or have been tampered with during the course of the authenticated session (e.g. session hijack, payment modification, device takeover).
It is impossible to separate the issue of risk judgement and acceptance of risk from liability. For example, a TPP might want to provide a consistent user experience to a PSU and be prepared to take the risks of this. E.g. in permitting lower security for a transaction. But this may exceed the ASPSP’s risk appetite. This risk should be very clearly for the account of the TPP. The way that an ASPSP is left having to pursue a TPP for the reimbursement of unauthorised transactions will lead to transaction costs and credit risk. It would seem only logical that a TPP that wanted to take such an approach should enter into enforceable contractual commitments to reimburse the ASPSP. There should be regulation on passing through of adequate device and transaction context details to make a risk based decision (not contact details as stated). Banks need to be able to authenticate and risk score the customer, the device used and the transaction and not just the customer which has tended to be the focus.
b. Device recognition is a key cornerstone of fraud prevention for online banking – however, often TPP’s do not pass details of the device initiating a transaction through which impedes risk based decisions by the bank.
b. VocaLink believe the concept of tokenisation (for example OAuth tokenisation) or one time access credentials which protect the underlying bank online credentials is a valid one, and means the logon credentials ideally should not be shared with ASPSP or PIS.
c. Even if recitals 32 and 30 were interpreted as mandating a PIS being able to directly submit payment instructions to an ASPSP, it should be possible for an ASPSP to be able to satisfy this obligation by saying that a PIS could directly initiate payments, albeit with better controls (instead of reusing bank issued credentials). For example:
1. By having the TPP have its own credentials with the ASPSP that the TPP can use to initiate payment on behalf of the consumer (so the bank issued consumer credentials do not need sharing with the TPP); and/or
2. Requiring some sort of transaction authentication code that the ASPSP issues to the consumer is key, perhaps by phone or a dongle, included in the TPP’s payment instruction to the ASPSP, so the ASPSP has evidence the specific transaction has really been authorised by the consumer.
b. Solutions based upon such tokenisation would be more elegant and give legally enforceable roles and boundaries, deciding where the risk lies.
c. If TPPs ONLY submit payment via such a medium it would seem reasonable to argue that a PIS did not give rise to any risk and therefore did not have to obtain insurance as a pre-condition to authorisation. So giving a route to avoiding one of the major potential barriers to entry for many PISs.
a. At the end users’ own device
b. anywhere credentials are stored en route
c. the point at which the credentials are processed i.e. PSP systems in memory while being passed onto the bank, there is already malware which does memory scraping for card details in point of sale devices that captures it while it is in flight.
d. Typically the TPP is the weakest link.
b. The point in para f would seem to support CAPS as a bank’s preferred access point for TPPs that they would have to adapt to, as long as CAPS was demonstrably compliant with the minimum technical requirements, for example OAuth tokenisation,
c. On point C, CAPS will provide a central routing service including which services each of the participants use/offer.
b. The particular standards could be policed by being required to adhere to PFMI style open membership and governance, a ‘scheme’ issue, with APIs being defined as standard(s).
b. Also, despite the e-IDAS, EBA’s SecuRe Pay and work on the Government identity schemes, they are currently not interoperable and don’t support cross border payments. Again the role / development of OAuth needs to be considered further.
a. It may be considered as a possible solution but should not be mandated. e-IDAS would create an artificial dependency and delaying factor. The obvious and most appropriate identification to build to would seem to be to bank’s KYC/CDD systems, which are specifically linked to payments accounts. e-IDAS is designed more with respect to government services use cases. The use of this identity by TPPs might also be a seen as creating a risk to the e-IDAS credentials.
Also, despite the e-IDAS, EBA’s SecuRe Pay and work on the Government identity schemes, they are currently not interoperable and don’t support cross border payments. Again the role / development of OAuth needs to be considered further.
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.
N/A2. 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?
N/A3. 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?
N/A4. 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)?
N/A5. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to dynamic linking?
a) VocaLink’s concern is how will a specific payee be identified, by name or sort code and account? The issue of fraud remains since banks don’t check the name of payees, and if it’s by numbers then it would facilitate frauds whereby the target account is owned by the fraudster. Should the banks build an entirely new way to validate identity if sort code/account number and name is not seen as sufficient? The non-banks would argue that the bank view of identity is relatively poor, and open to fraud? Although different banks take very different approaches to risk. Arguably there is a role for the Government owned digital identity scheme here, to provide more robust validation, but it seems more likely that it will follow industry standards such as OAuth, in due course.Sort code and account number is not used to for strong customer identity online but might well be used for identifying where a payment is going to via the TPP. Creating a new mechanism for routing the payment is pointless as these two things are required to route a payment via whatever mechanism underlies the bank transfer (i.e. faster payments, CHAPS, BACS). There is no appetite for a government owned digital identity scheme (and in fact the government is looking to piggyback bank strong customer authentication for their own services in the future).
6. In your view, which solutions for mobile devices fulfil both the objective of independence and dynamic linking already today?
a. Electronic payments are rapidly moving to tokenisation for their security; this protects the underlying and static financial instrument (e.g. PAN number, bank details) while providing a one-time transaction code that can be linked back to the originating device. This underlies newer contactless payment transaction such as Applepay, Google wallet and Samsung pay via mobiles.b. It is clear that any solution should provide a layer of abstraction which hides the underlying account details, for example Pay by Bank app™ (Zapp).
Zapp does hide the account details from the merchant. It leverages the users mobile bank app. The merchant generates a code, via Zapp, that the user puts into his bank app. The bank retrieves the payment details from VocaLink using the code and makes a faster payment, at which point the merchant is informed that it has been paid.
The user experience is as follows: Clicking the Pay by Bank app™ symbol online will automatically open a consumer’s bank app on their phone. Once securely logged in, they can quickly complete their payment. Consumers will be able to see their account balances before they pay and choose different accounts to pay from, thereby staying more in control of their finances.
NB it provides a layer of abstraction like apple pay and others which hides the underlying account details.
c. PayM, for example uses Dynamic Linking to confirm the amount and payee before releasing the payment instruction.
d. MyPINpad, for example is provided for this purpose, to obtain confirmation by a payer that the specific transaction is indeed approved by the payer: i.e. the PIS has not created a spoof transaction.
7. Do you consider the clarifications suggested regarding the potential exemptions to strong customer authentication, to be useful?
N/A8. Are there any other factors the EBA should consider when deciding on the exemptions applicable to the forthcoming regulatory technical standards?
a. The key issue which seems to be omitted is that in a transaction, involving a TPP and an ASPSP, is they will each need to independently make their own subjective risk judgement. There is no reason that these should be the same for each transaction. In fact there is every likelihood that they will differ.b. It is no longer adequate to authenticate just the user; best of breed banks authenticate the user, the device and the actual transaction to ensure that none of them are anomalous or have been tampered with during the course of the authenticated session (e.g. session hijack, payment modification, device takeover).
It is impossible to separate the issue of risk judgement and acceptance of risk from liability. For example, a TPP might want to provide a consistent user experience to a PSU and be prepared to take the risks of this. E.g. in permitting lower security for a transaction. But this may exceed the ASPSP’s risk appetite. This risk should be very clearly for the account of the TPP. The way that an ASPSP is left having to pursue a TPP for the reimbursement of unauthorised transactions will lead to transaction costs and credit risk. It would seem only logical that a TPP that wanted to take such an approach should enter into enforceable contractual commitments to reimburse the ASPSP. There should be regulation on passing through of adequate device and transaction context details to make a risk based decision (not contact details as stated). Banks need to be able to authenticate and risk score the customer, the device used and the transaction and not just the customer which has tended to be the focus.
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?
a. The view a TPP and an AS PSP would have of each of the factors in para 45 would differ unless a PSU used only one TPP and one ASPSP and initiated all of its transactions via the TPP.b. Device recognition is a key cornerstone of fraud prevention for online banking – however, often TPP’s do not pass details of the device initiating a transaction through which impedes risk based decisions by the bank.
10. Do you consider the clarification suggested regarding the protection of users personalised security credentials to be useful?
Yes, but these need to go further as discussed in questions 8 and 9 above.11. What other risks with regard to the protection of users’ personalised security credentials do you identify?
a. The major risk that TPP potentially creates is if PSUs are to reuse their ASPSP-issued credentials when initiating transactions via TPPs. This is particularly concerning since “An AS PSP which provides a mechanism for indirect access should also allow direct access for the PIS providers” recital 32 has been interpreted by many TPPs and some authorities to effectively mandate overlay services whereby consumers can use their bank credentials at TPPs to initiate payments at ASPSPs. Presumably on the basis of additional protections that TPPs need to identify when they are initiating payments, and TPPs being regulated.b. VocaLink believe the concept of tokenisation (for example OAuth tokenisation) or one time access credentials which protect the underlying bank online credentials is a valid one, and means the logon credentials ideally should not be shared with ASPSP or PIS.
c. Even if recitals 32 and 30 were interpreted as mandating a PIS being able to directly submit payment instructions to an ASPSP, it should be possible for an ASPSP to be able to satisfy this obligation by saying that a PIS could directly initiate payments, albeit with better controls (instead of reusing bank issued credentials). For example:
1. By having the TPP have its own credentials with the ASPSP that the TPP can use to initiate payment on behalf of the consumer (so the bank issued consumer credentials do not need sharing with the TPP); and/or
2. Requiring some sort of transaction authentication code that the ASPSP issues to the consumer is key, perhaps by phone or a dongle, included in the TPP’s payment instruction to the ASPSP, so the ASPSP has evidence the specific transaction has really been authorised by the consumer.
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?
a. VocaLink believe the concept of tokenisation (for example OAuth tokenisation) or one time access credentials which protect the underlying bank online credentials is a valid one, and means the logon credentials ideally should not be shared with ASPSP or PIS.b. Solutions based upon such tokenisation would be more elegant and give legally enforceable roles and boundaries, deciding where the risk lies.
c. If TPPs ONLY submit payment via such a medium it would seem reasonable to argue that a PIS did not give rise to any risk and therefore did not have to obtain insurance as a pre-condition to authorisation. So giving a route to avoiding one of the major potential barriers to entry for many PISs.
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?
a. CAPS will have elements of fraud scoring, confidence score and trigger codes. It will also offer connectivity options for TPP’s and ASPSP’s above internet (bank API). All parties (TPP’s, ASPSP’s and intermediaries) should have up to date and relevant security protocols. Re TPP’s, a check of this should be done on registration. This may benefit from increased definition of standards, with policing via appropriate bodies, e.g. schemes.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?
There are a number of points where security credentials are vulnerable:a. At the end users’ own device
b. anywhere credentials are stored en route
c. the point at which the credentials are processed i.e. PSP systems in memory while being passed onto the bank, there is already malware which does memory scraping for card details in point of sale devices that captures it while it is in flight.
d. Typically the TPP is the weakest link.
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?
a. Whilst standards need to be “common” and “open” consideration must be given to “how” they know it’s an approved solution?b. The point in para f would seem to support CAPS as a bank’s preferred access point for TPPs that they would have to adapt to, as long as CAPS was demonstrably compliant with the minimum technical requirements, for example OAuth tokenisation,
c. On point C, CAPS will provide a central routing service including which services each of the participants use/offer.
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?
As for 1517. 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 for 1518. 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)?
a. It would reasonable to suggest that the over-arching standards should be maintained within an appropriate standards body, or perhaps using OAuth standard fieldsb. The particular standards could be policed by being required to adhere to PFMI style open membership and governance, a ‘scheme’ issue, with APIs being defined as standard(s).
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.
a. It may be considered as a possible solution but should not be mandated. e-IDAS would create an artificial dependency and delaying factor. The obvious and most appropriate identification to build to would seem to be to bank’s KYC/CDD systems, which are specifically linked to payments accounts. e-IDAS is designed more with respect to government services use cases. The use of this identity by TPPs might also be a seen as creating a risk to the e-IDAS credentials.b. Also, despite the e-IDAS, EBA’s SecuRe Pay and work on the Government identity schemes, they are currently not interoperable and don’t support cross border payments. Again the role / development of OAuth needs to be considered further.
20. Do you think in particular that the use of “qualified trust services” under e-IDAS regulation could address the risks related to the confidentiality, integrity and availability of PSCs between AIS, PIS providers and ASPSPs? If yes, please identify which services and explain how. If no, please explain why.
As for 19,a. It may be considered as a possible solution but should not be mandated. e-IDAS would create an artificial dependency and delaying factor. The obvious and most appropriate identification to build to would seem to be to bank’s KYC/CDD systems, which are specifically linked to payments accounts. e-IDAS is designed more with respect to government services use cases. The use of this identity by TPPs might also be a seen as creating a risk to the e-IDAS credentials.
Also, despite the e-IDAS, EBA’s SecuRe Pay and work on the Government identity schemes, they are currently not interoperable and don’t support cross border payments. Again the role / development of OAuth needs to be considered further.