Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
We are concerned that many of the actors in the payment arena have undue market power and influence, and, that without clear and concise requirements within the Regulatory Technical Standard (RTS), that they may use market position to stifle innovation.
In our view the general approach of the Consultation Paper and the draft RTS is correct, and we see little in either with which to take issue.
We agree that a principles-based approach, rather than a specific technical solution is the correct approach, as this allows the potential for innovation and competition.
One point on which we have disagreed with the approach of the EBA is in relation to ‘mandatory’ application of exemptions to Strong Customer Authentication, as we would prefer to see any exemption to be at the discretion of the PISP.
Yes, subject to qualifications about recurring payments, one-leg-out transactions, and the role of the Governance Authority below.
As noted above, we agree in particular that the RTS should not adopt a specific technical or business approach, but rather a neutral, principle-based one.
iSignthis is also supportive of the requirement for regular review of Strong Customer Authentication procedures.
Recurring Transactions
In order to give proper effect to the intention of the Directive, and balance the competing objectives of authentication and ease of transactions, we submit that recurring transactions be subject to strong customer authentication at setup or with first transaction. This could be achieved by apply strong customer authentication to either authorise the total amount to be paid over an agreed period, or to authorise the periodic payment for a given number of periods.
iSignthis submits that excluding recurring payments from the scope of the strong customer authentication, or exempting them from the applicability of strong customer authentication, is contrary to the underlying principles of the Directive. We do not believe that it is burdensome to require strong customer authentication of recurring payments by one of the means suggested above.
In this respect we submit that hybrid payment/cart systems such as SamsungPay, AndroidPay and ApplePay are within the scope of the Directive for the registration of cards to the cart systems, and for subsequent transactions. Similarly, e-Wallets are within scope.
In our submission, the EBA should clarify this in the final RTS.
One-leg-transactions
We note that one-leg-out transaction authentication is consistent with the ECB’s position per January 2013 “Recommendations for the Security of Internet Payments: Outcome of the Public Consultation”, Page 2, Section 6 “Implementation Issues”.
There is no in principle reason why one-leg-transactions should not be subject to strong customer authentication. European merchants and PSPs should expect protection when accepting cards by consumers located outside the EEA. Given the increased emphasis on money laundering, tax avoidance and counter funding for terrorism, there is are compelling reasons for EEA regulated PSPs to apply Strong Customer Authentication to card holders located outside the EEA, when these consumers make purchases from merchants within the EEA.
Further, despite the regularly made assertion that “not all markets outside the EEA support strong customer authentication”, this is in fact an outdated notion. It is true that some systems which can apply strong customer authentication, such as 3DSecure, are not widely adopted, and that they require direct participation by the issuers, the acquirer and the merchant. It is also true that some systems, again such as 3DSecure, lead to high rates of customer abandonment, as cardholders are often reluctant to register their card.
Nevertheless, fostered in part by technology and process neutral regulation, solutions to issues such as one-leg-out authentication have emerged. iSignthis is such a solution.
iSignthis can implement strong customer authentication for one-leg-transactions, regardless of whether the acquiring or issuing PSP (or card holder or merchant) is resident in or outside the EEA. Unlike 3D Secure that requires all three domains (merchant, acquirer and issuer) to be technically and commercially bound to the process, iSignthis uses the global card scheme rules as its commercial framework, and requires only technical connection to the merchant through its acquiring PSP.
The card holders personal security credentials, as managed by the issuing PSP, are incorporated and used as part of an out of band authentication process to register a cardholder to the iSignthis Strong Customer Authentication process, irrespective of the location of the issuing PSP.
iSignthis can also interact technically with the issuing PSP using an in-band mode, similar to 3DSecure.
Seperately, and at the merchant’s option, iSignthis may incorporate 3DSecure as part of its registration process, provided that both issuer and card are enrolled.
Further, the iSignthis process can be used as the basis of remote, enhanced due diligence to satisfy the 3AMLD or 4AMLD.
An outline of the iSignthis Payment Instrument Verification process is set out at the bottom of this answer*.
Governance Authority
Whilst outside of the scope of the RTS and the EBA, the RTS relies upon the Governance Authority implementing a liability shift regime, per the ECB Recommendations for the Security of Internet Payments, Key Consideration 7.6.
7.6 KC All payment schemes should promote the implementation of strong customer authentication by introducing a liability regime for the participating PSPs in and across all European markets.
It is noted that a footnote to 7.6 KC provides that: “[t]he liability regime should provide that a PSP must refund other PSPs for any fraud resulting from weak customer authentication.”
The Governance Authority operating rules should be updated to reflect that any technological or business solution that meets compliance with the RTS will automatically be taken to provide a basis to apply the liability shift mechanism.
*The iSignthis process
We advise that the merchant uses the iSignthis process, which process proves control of the account and authenticates transactions by use of a dynamic one time secret inserted into the transaction process. The secret is retrieable only through accessing the online, mobile or telephone banking/account associated with the card. The only person who can legitimately access this secret is the Card Holder, through the use of their personal security credentials as provided by their card Issuer.
In the Registration Responses section of the attached Dispute Report, it can be noted that the dynamic secret was correctly retrieved from the Card Holder’s account by a person with access to that account.
The secret is computer generated by dividing the Sales Amount transaction into two partial pre-payment amounts, whereby the Product will be delivered after the secret has been confirmed by the Card Holder. The two pre-payments are a random pre-payment, and a balancing item pre-payment, summing to the total Sales Amount agreed to be paid by the Card Holder.
The secret is computer generated by iSignthis without either the cardholder or the merchant being advised of the value of the two partial prepayment amounts, with the cardholder only being advised that the two prepayments will sum to the agreed sales value between the merchant and cardholder (consistent with Table 5-17 of the Visa Core Rules and Visa Product and Service Rules, April 2016). The value of each of the prepayment1 and prepayment2 is thus a secret that can only be known once retrieved by the card holder by accessing their secure banking/transaction account portal using the personal security credentials provided by the card issuer.
The cardholder has a maximum of three attempts to provide the secret value of prepayment1 and prepayment2, which in turn provides a high degree of entropy with regards to security and probabilistic opportunity of success. The merchant is advised of the value of each of the prepayment1 and prepayment2 only upon successful confirmation from the cardholder to iSignthis. The process is entirely automated, without any human intervention or access possible by iSignthis (as the merchant agent), the acquirer or the issuer.
Where the cardholder does not respond within 3 business days, the two partial prepayment amounts are refunded back to the card and the sales order cancelled. Thus, the merchant does not ship until satisfaction of the iSignthis process, qualifying each of the transactions to be considered as partial prepayments, rather than two separate sales capture transactions.
iSignthis logs geolocation, browser characteristics, GPS location (from device, where available) and other metadata as part of the process, and as recorded below.
The iSignthis process also verifies possession of a mobile telephone via a one time passcode, and links the card to the phone upon a correct reponse by the cardholder, such that subsequent transactions may be authenticated by use of a one time passcode sent to the mobile telephone and a user selected PIN or password. These transactions are nominated as “authentication” transactions.
The EBA should address the means and conditions for true independence of channels or bands within a single device, such as the GSM SMS channel/band versus the IP protocol channel/band. If the device is unlocked in its entirety, or the channels are unlocked, we posit that separation does not in fact exist.
We submit that the use of biometric or PIN control be required to access any dedicated application on the device that is involved in the strong customer authentication, irrespective of whether it operates in conjunction with or standalone to a browser.
In our earlier submission we noted that:
“ … human and technological limitations may mean the dynamic one-time code appears ‘in the clear’ on an unlocked phone. In some cases, the phone may temporarily display SMS even on a locked screen. Similarly, authentication applications (and some banking apps) display the one-time code as a notification, that is retrievable without needing to log into the application itself.
Browsers (or apps on mobile) should not allow storing of passwords, as a dynamic element transmitted via app or SMS may be visible to persons accessing phone, together both of which would defeat security entirely.
Some of these challenges are akin to weak passwords or PINs, and guidance to obligated entities to instigate contractual and technological means to deter and prevent PSU conduct that raises these challenges could be helpful.”
For completeness we submit that the threat of the device associated possession element being shared between persons could be added to Article 4, such that only one device associated with the possession elements is linked to one payment services user. This would allow one device to be shared, linked or re-used across multiple cards and/or ewallet accounts associated with one payment user.
Article 8.1 (a) (i) and (ii): We interpret “information of its payment account online” to include only institution, persons name and account number. We also interpret consolidated information as being an account balance, but not transaction specific details such as a specific transaction amount.
We seek this clarification as some ASPSPs transmit the transaction amount to devices such as the Apple Watch or iPhone, without any access security as contemplated in Article 8.1 (a)(i) and (ii).
The PSD2 Article 4 (32) provides that only name and account details are considered not to be sensitive payment data. That is, by deduction, all other data is therefore confidential payment data and should be subject to access only under Strong Customer Authentication, other than where exempted by Article 8.2 (a)(i) and (ii).
With regards to Article 8.2 (d): We submit that the “cumulative amount” limit on exemptions under Article 8.2 (d)(ii) should themselves be time limited, to say a daily limit.
The purpose of such exemptions is avoid burdening businesses and consumers with disproportionate process for low value transactions. It can also assist in reducing the risks of cash holding if low value transactions can be made electronically.
We further posit that the cumulative limit should be on a per merchant basis, and managed by the merchant’s PSP.
This would allow merchant’s PSP’s to monitor floor limits dynamically, without the requirement to authorise each transaction in advance of Strong Customer Authentication, which would likely burden the processing network infrastructure. It also has the benefit that it may allow for development of technology neutral means of Strong Customer Authentication, which could be applied in remote transactions where there is not an ‘always on’ network (eg airline, ferries, trains etc) back to the issuer.
In the event the issuer is managing the limits, the issuer will likely need to utilise a new secure communications channel to communicate with the merchant’s PSP in relation to the limits or Strong Customer Authentication reset mechanism. This may prove complex given the number of cards schemes, issuers and acquirers in the SEPA zone, and would likely need to be developed and operated by each Governance Authority as part of the processing framework.
This channel could be used by the PSP to communicate back to the issuer risk based analytics or if alternative (non issuer originated) Strong Customer Authentication means have been used.
We do not believe that a PSP (or merchant) should be prevented from implementing Strong Customer Authentication.
If prevention of application of Strong Customer Authentication is to be mandated (as opposed to being at the merchant’s or PISP’s risk), then, in the circumstances of exempt transactions, we have a concern regarding the liability for any fraud, particularly under the ECB’s Guidelines (per Question 1) and the liability shift regime to be implemented by each Governance Authority.
It is unclear whether it is the issuing ASPSP or the acquiring PISP (and thus the merchant), who would be liable for any fraud in such a circumstance. It is unclear if Article 73 or Article 74 of the PSD2 would be applicable.
Not allowing an acquiring PISP to implement strong customer authentication in circumstances where the exemption criteria is met is in our submission antithetical to the purpose of Article 73 of the PSD2, that seeks to determine which PSP is liable for fraud. It also contradicts the explicit basis for the RTS in Article 98.3, which provides that exemptions be based on (inter alia) “ … the level of risk involved in the service.”
By way of comparison, the Third and Fourth Anti-Money Laundering Directives take the opposite approach, as do the implementing rules made under them.
The exemptions are, as outlined above, designed to avoid burdening businesses and consumers with disproportionate process for low value transactions. However, it is not the case that transactions falling within the exemption criteria are “no risk” or indeed that all low value transactions are low risk. This is recognised by the cumulative limits cap, which provides a means for high risk and low value transactions to be limited.
It is likely that in some cases of low value transactions, the PSP will be on actual notice, or have suspicions as to the authenticity of the user of a payment instrument. Not being able to implement strong customer authentication in such circumstances is, in our submission, contrary to the purpose of the PSD2. It could place the PSP or relevant merchant in the position of breaching the AML Directive
It is our view that persistent adherence of Strong Customer Authentication is consistent with the aim of the AML directive.
In our submission, the balance between not being permitted to implement strong customer authentication by exception when the criteria for exemption exist, and not having the exempt circumstances is clearly in favour of not having the exemptions.
In addition to the issues already noted, the impermissibility of implementing strong customer authentication by exception would be an unreasonable burden on merchant who would in such circumstances be unable to prevent fraud, but would nevertheless in all likelihood be forced to bear the burden of the cost of fraud, as consumers would under payment card rules have strong grounds to have the transaction reversed as a chargeback.
It is our view that the application of the approach proposed in the draft RTS would lead to a regulatory regime which would detract from consumer and merchant confidence in on line payments.
We believe that it is desirable for the EBA to clarify that exemptions are optional and not mandatory. As fraud patterns change, PSPs should be given the opportunity to apply strong customer authentication, as and when they deem appropriate, which should also be applicable for low value payments.
Therefore, we would request that the EBA consider changing the mandatory requirement of Article 8 of the RTS to a discretionary requirement, by substituting ‘may be’ for ‘is’ in the first line of Article 8 (1) and Article 8 (2).
Article 12 of the RTS allows a servicing PSP other than the issuing PSP to utilise the Personalised Security Credentials of the issuing ASPSP to link the user to Personal Security Credentials of the AIPSP or acquiring PISP. This is sensible, as both AIPSP and PISP should be able to rely on the ASPSP’s authentication measures and Personal Security Credentials in order to create their own Personal Security Measures, which should, subject to compliance with this RTS, be treated as equivalent.
Article 14 and 16 could be augmented with guidance as to the minimum frequency of renewal of the AIPSP and PISP personal security credentials (eg at least annually), as the text refers to the period of review of the associated procedures rather than the period between issue or renewal.
Article 16 could also be subject to a risk based approach for re-issue of personalised security credentials, in conjunction with a regular (minimum) periodic renewal.
We note that both PayPal and iSignthis have automated and remote means to verify ownership of a payment instrument, perform customer due diligence and link these to their own personalized security credentials. Both PayPal and iSignthis rely upon the “……use of the users personalised security credentials” as provided by the ASPSP, as part of their respective processes. Similarly, it is our understanding that Yodlee, an AIPSP, requires the use of the ASPSP personalised security credentials in the first instance, in order to link the PSU to Yodlee credentials for subsequent activities.
In the above cases, the PSU must “use” the issuing ASPSP’s personal security credentials in order to link a card or account to a further PSP’s service. Both PayPal and iSignthis achieve this by use of transmitting a secret to the PSU’s secure portal (eg their bank portal), and the PSU must retrieve the secret and confirm it to PayPal or iSignthis in order to link accounts from their existing PSP to a 3rd party PSP. Retrieval of the ‘secret’ requires “use” of the ASPSP’s personalised security credentials as part of the process.
The indirect identity payment instrument verification and authentication process used by PayPal and iSignthis has advantages in that it avoids Man in the middle, Boy in the browser, or security breach attacks, as may be the case via any exposed API with a third party user interface.
This indirect means ensures that the integrity of the issuing ASPSP’s security is not compromised by attack vectors that become available via direct API access. Whilst both companies have their own patented processes, their processes allow identification of a customer remotely, and subsequent issue of credentials via a range of physically and logically separated system.
All of the iSignthis, PayPal and Yodlee approaches allow for ‘one leg out’ authentication, where the ASPSP is outside the EU/SEPA, with the PISP being inside the SEPA. We note that both iSignthis and PayPal use an out of band method to authenticate by including the use of the users personal security credentials. The use of an out of band channel as part of an authentication process forms part of US FFIEC Guidance, as it mitigates against certain security threats, by layering security.
We note that the major card schemes have mandated EMVCo to develop next generation 3D Secure, incorporating 2FA and mobile features. EMVCO’s second generation 3D Secure incorporating 2FA is still as yet not released, and it will likely require significant investment by the ASPSP’s in order to comply with this RTS. Use of existing ASPSP personalised security credentials as part of the PISP process, either directly, indirectly or out of band, will provide industry with options.
However, in the event that no or only a limited number of qualified trust service providers were designated under e-IDAS, clearly a different approach will be needed.
We do not agree that a feasible alternative is to permit the use of website certificates issued by a general Certificate Authority.
Certificates are issued with sometimes only cursory due diligence by the Certificate Authority. Too much responsibility would need to be placed on the Certificate Authority to check that the applicant is registered, holds licenses, etc etc. Further, Certificate Authorities are often located outside the jurisdiction of the EBA.
In our submission, this would clearly require alternative processes to be adopted by ASPSPs to verify the registration number, despite the burden this places on them.
We note that even the Extended Validation (EV) certificate providers do not perform customer due diligence to the standard level required under the 4th AML Directive.
Extended Validation certificates are the highest class of SSL certificates available. EV SSL Certificates offer a stronger guarantee that the owner of the website passed a thorough, and globally standardized, identity verification process defined within the EV guidelines for SSL certificates.
The Extended Validation identity verification process requires the applicant to prove exclusive rights to use a domain, confirm its legal, operational and physical existence, and technically prove that the entity to which the certificate was issued has authorized the issuance of the Certificate. However, there is no check on the Company’s certified accreditations (eg ISO27001, PCI-DSS), directors, ultimate beneficial owners and so forth, or that the company is licensed to participate as a Payment Services Provider.
Dormancy is also an issue, as a user may cease practical use of a service, but may not deactivate an account with AISP for some time. Under such scenario, we see the introduction of unnecessary risks due to data transport and distribution of sensitive data, with no corresponding benefit to AISP, PSP or end user.
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?
iSignthis provided a submission to the EBA’s earlier Discussion paper (EBA/DP/2015/03). We believe our earlier submission remains relevant and are pleased to note that in general they are in conformity with the proposals of the EBA in the Consultation Paper and the draft Regulatory Technical Standards.We are concerned that many of the actors in the payment arena have undue market power and influence, and, that without clear and concise requirements within the Regulatory Technical Standard (RTS), that they may use market position to stifle innovation.
In our view the general approach of the Consultation Paper and the draft RTS is correct, and we see little in either with which to take issue.
We agree that a principles-based approach, rather than a specific technical solution is the correct approach, as this allows the potential for innovation and competition.
One point on which we have disagreed with the approach of the EBA is in relation to ‘mandatory’ application of exemptions to Strong Customer Authentication, as we would prefer to see any exemption to be at the discretion of the PISP.
Yes, subject to qualifications about recurring payments, one-leg-out transactions, and the role of the Governance Authority below.
As noted above, we agree in particular that the RTS should not adopt a specific technical or business approach, but rather a neutral, principle-based one.
iSignthis is also supportive of the requirement for regular review of Strong Customer Authentication procedures.
Recurring Transactions
In order to give proper effect to the intention of the Directive, and balance the competing objectives of authentication and ease of transactions, we submit that recurring transactions be subject to strong customer authentication at setup or with first transaction. This could be achieved by apply strong customer authentication to either authorise the total amount to be paid over an agreed period, or to authorise the periodic payment for a given number of periods.
iSignthis submits that excluding recurring payments from the scope of the strong customer authentication, or exempting them from the applicability of strong customer authentication, is contrary to the underlying principles of the Directive. We do not believe that it is burdensome to require strong customer authentication of recurring payments by one of the means suggested above.
In this respect we submit that hybrid payment/cart systems such as SamsungPay, AndroidPay and ApplePay are within the scope of the Directive for the registration of cards to the cart systems, and for subsequent transactions. Similarly, e-Wallets are within scope.
In our submission, the EBA should clarify this in the final RTS.
One-leg-transactions
We note that one-leg-out transaction authentication is consistent with the ECB’s position per January 2013 “Recommendations for the Security of Internet Payments: Outcome of the Public Consultation”, Page 2, Section 6 “Implementation Issues”.
There is no in principle reason why one-leg-transactions should not be subject to strong customer authentication. European merchants and PSPs should expect protection when accepting cards by consumers located outside the EEA. Given the increased emphasis on money laundering, tax avoidance and counter funding for terrorism, there is are compelling reasons for EEA regulated PSPs to apply Strong Customer Authentication to card holders located outside the EEA, when these consumers make purchases from merchants within the EEA.
Further, despite the regularly made assertion that “not all markets outside the EEA support strong customer authentication”, this is in fact an outdated notion. It is true that some systems which can apply strong customer authentication, such as 3DSecure, are not widely adopted, and that they require direct participation by the issuers, the acquirer and the merchant. It is also true that some systems, again such as 3DSecure, lead to high rates of customer abandonment, as cardholders are often reluctant to register their card.
Nevertheless, fostered in part by technology and process neutral regulation, solutions to issues such as one-leg-out authentication have emerged. iSignthis is such a solution.
iSignthis can implement strong customer authentication for one-leg-transactions, regardless of whether the acquiring or issuing PSP (or card holder or merchant) is resident in or outside the EEA. Unlike 3D Secure that requires all three domains (merchant, acquirer and issuer) to be technically and commercially bound to the process, iSignthis uses the global card scheme rules as its commercial framework, and requires only technical connection to the merchant through its acquiring PSP.
The card holders personal security credentials, as managed by the issuing PSP, are incorporated and used as part of an out of band authentication process to register a cardholder to the iSignthis Strong Customer Authentication process, irrespective of the location of the issuing PSP.
iSignthis can also interact technically with the issuing PSP using an in-band mode, similar to 3DSecure.
Seperately, and at the merchant’s option, iSignthis may incorporate 3DSecure as part of its registration process, provided that both issuer and card are enrolled.
Further, the iSignthis process can be used as the basis of remote, enhanced due diligence to satisfy the 3AMLD or 4AMLD.
An outline of the iSignthis Payment Instrument Verification process is set out at the bottom of this answer*.
Governance Authority
Whilst outside of the scope of the RTS and the EBA, the RTS relies upon the Governance Authority implementing a liability shift regime, per the ECB Recommendations for the Security of Internet Payments, Key Consideration 7.6.
7.6 KC All payment schemes should promote the implementation of strong customer authentication by introducing a liability regime for the participating PSPs in and across all European markets.
It is noted that a footnote to 7.6 KC provides that: “[t]he liability regime should provide that a PSP must refund other PSPs for any fraud resulting from weak customer authentication.”
The Governance Authority operating rules should be updated to reflect that any technological or business solution that meets compliance with the RTS will automatically be taken to provide a basis to apply the liability shift mechanism.
*The iSignthis process
We advise that the merchant uses the iSignthis process, which process proves control of the account and authenticates transactions by use of a dynamic one time secret inserted into the transaction process. The secret is retrieable only through accessing the online, mobile or telephone banking/account associated with the card. The only person who can legitimately access this secret is the Card Holder, through the use of their personal security credentials as provided by their card Issuer.
In the Registration Responses section of the attached Dispute Report, it can be noted that the dynamic secret was correctly retrieved from the Card Holder’s account by a person with access to that account.
The secret is computer generated by dividing the Sales Amount transaction into two partial pre-payment amounts, whereby the Product will be delivered after the secret has been confirmed by the Card Holder. The two pre-payments are a random pre-payment, and a balancing item pre-payment, summing to the total Sales Amount agreed to be paid by the Card Holder.
The secret is computer generated by iSignthis without either the cardholder or the merchant being advised of the value of the two partial prepayment amounts, with the cardholder only being advised that the two prepayments will sum to the agreed sales value between the merchant and cardholder (consistent with Table 5-17 of the Visa Core Rules and Visa Product and Service Rules, April 2016). The value of each of the prepayment1 and prepayment2 is thus a secret that can only be known once retrieved by the card holder by accessing their secure banking/transaction account portal using the personal security credentials provided by the card issuer.
The cardholder has a maximum of three attempts to provide the secret value of prepayment1 and prepayment2, which in turn provides a high degree of entropy with regards to security and probabilistic opportunity of success. The merchant is advised of the value of each of the prepayment1 and prepayment2 only upon successful confirmation from the cardholder to iSignthis. The process is entirely automated, without any human intervention or access possible by iSignthis (as the merchant agent), the acquirer or the issuer.
Where the cardholder does not respond within 3 business days, the two partial prepayment amounts are refunded back to the card and the sales order cancelled. Thus, the merchant does not ship until satisfaction of the iSignthis process, qualifying each of the transactions to be considered as partial prepayments, rather than two separate sales capture transactions.
iSignthis logs geolocation, browser characteristics, GPS location (from device, where available) and other metadata as part of the process, and as recorded below.
The iSignthis process also verifies possession of a mobile telephone via a one time passcode, and links the card to the phone upon a correct reponse by the cardholder, such that subsequent transactions may be authenticated by use of a one time passcode sent to the mobile telephone and a user selected PIN or password. These transactions are nominated as “authentication” transactions.
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.
Yes, and in particular we support the condition of segregation.The EBA should address the means and conditions for true independence of channels or bands within a single device, such as the GSM SMS channel/band versus the IP protocol channel/band. If the device is unlocked in its entirety, or the channels are unlocked, we posit that separation does not in fact exist.
We submit that the use of biometric or PIN control be required to access any dedicated application on the device that is involved in the strong customer authentication, irrespective of whether it operates in conjunction with or standalone to a browser.
In our earlier submission we noted that:
“ … human and technological limitations may mean the dynamic one-time code appears ‘in the clear’ on an unlocked phone. In some cases, the phone may temporarily display SMS even on a locked screen. Similarly, authentication applications (and some banking apps) display the one-time code as a notification, that is retrievable without needing to log into the application itself.
Browsers (or apps on mobile) should not allow storing of passwords, as a dynamic element transmitted via app or SMS may be visible to persons accessing phone, together both of which would defeat security entirely.
Some of these challenges are akin to weak passwords or PINs, and guidance to obligated entities to instigate contractual and technological means to deter and prevent PSU conduct that raises these challenges could be helpful.”
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?
The threats against the authentication elements are in our submission broadly defined and so it is difficult to envision other threats.For completeness we submit that the threat of the device associated possession element being shared between persons could be added to Article 4, such that only one device associated with the possession elements is linked to one payment services user. This would allow one device to be shared, linked or re-used across multiple cards and/or ewallet accounts associated with one payment user.
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?
iSignthis agrees with the reasoning of the EBA on the exemptions set out in Chapter 2.Article 8.1 (a) (i) and (ii): We interpret “information of its payment account online” to include only institution, persons name and account number. We also interpret consolidated information as being an account balance, but not transaction specific details such as a specific transaction amount.
We seek this clarification as some ASPSPs transmit the transaction amount to devices such as the Apple Watch or iPhone, without any access security as contemplated in Article 8.1 (a)(i) and (ii).
The PSD2 Article 4 (32) provides that only name and account details are considered not to be sensitive payment data. That is, by deduction, all other data is therefore confidential payment data and should be subject to access only under Strong Customer Authentication, other than where exempted by Article 8.2 (a)(i) and (ii).
With regards to Article 8.2 (d): We submit that the “cumulative amount” limit on exemptions under Article 8.2 (d)(ii) should themselves be time limited, to say a daily limit.
The purpose of such exemptions is avoid burdening businesses and consumers with disproportionate process for low value transactions. It can also assist in reducing the risks of cash holding if low value transactions can be made electronically.
We further posit that the cumulative limit should be on a per merchant basis, and managed by the merchant’s PSP.
This would allow merchant’s PSP’s to monitor floor limits dynamically, without the requirement to authorise each transaction in advance of Strong Customer Authentication, which would likely burden the processing network infrastructure. It also has the benefit that it may allow for development of technology neutral means of Strong Customer Authentication, which could be applied in remote transactions where there is not an ‘always on’ network (eg airline, ferries, trains etc) back to the issuer.
In the event the issuer is managing the limits, the issuer will likely need to utilise a new secure communications channel to communicate with the merchant’s PSP in relation to the limits or Strong Customer Authentication reset mechanism. This may prove complex given the number of cards schemes, issuers and acquirers in the SEPA zone, and would likely need to be developed and operated by each Governance Authority as part of the processing framework.
This channel could be used by the PSP to communicate back to the issuer risk based analytics or if alternative (non issuer originated) Strong Customer Authentication means have been used.
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?
iSignthis is supportive of the exemptions, and believes that they appear sensible.We do not believe that a PSP (or merchant) should be prevented from implementing Strong Customer Authentication.
If prevention of application of Strong Customer Authentication is to be mandated (as opposed to being at the merchant’s or PISP’s risk), then, in the circumstances of exempt transactions, we have a concern regarding the liability for any fraud, particularly under the ECB’s Guidelines (per Question 1) and the liability shift regime to be implemented by each Governance Authority.
It is unclear whether it is the issuing ASPSP or the acquiring PISP (and thus the merchant), who would be liable for any fraud in such a circumstance. It is unclear if Article 73 or Article 74 of the PSD2 would be applicable.
Not allowing an acquiring PISP to implement strong customer authentication in circumstances where the exemption criteria is met is in our submission antithetical to the purpose of Article 73 of the PSD2, that seeks to determine which PSP is liable for fraud. It also contradicts the explicit basis for the RTS in Article 98.3, which provides that exemptions be based on (inter alia) “ … the level of risk involved in the service.”
By way of comparison, the Third and Fourth Anti-Money Laundering Directives take the opposite approach, as do the implementing rules made under them.
The exemptions are, as outlined above, designed to avoid burdening businesses and consumers with disproportionate process for low value transactions. However, it is not the case that transactions falling within the exemption criteria are “no risk” or indeed that all low value transactions are low risk. This is recognised by the cumulative limits cap, which provides a means for high risk and low value transactions to be limited.
It is likely that in some cases of low value transactions, the PSP will be on actual notice, or have suspicions as to the authenticity of the user of a payment instrument. Not being able to implement strong customer authentication in such circumstances is, in our submission, contrary to the purpose of the PSD2. It could place the PSP or relevant merchant in the position of breaching the AML Directive
It is our view that persistent adherence of Strong Customer Authentication is consistent with the aim of the AML directive.
In our submission, the balance between not being permitted to implement strong customer authentication by exception when the criteria for exemption exist, and not having the exempt circumstances is clearly in favour of not having the exemptions.
In addition to the issues already noted, the impermissibility of implementing strong customer authentication by exception would be an unreasonable burden on merchant who would in such circumstances be unable to prevent fraud, but would nevertheless in all likelihood be forced to bear the burden of the cost of fraud, as consumers would under payment card rules have strong grounds to have the transaction reversed as a chargeback.
It is our view that the application of the approach proposed in the draft RTS would lead to a regulatory regime which would detract from consumer and merchant confidence in on line payments.
We believe that it is desirable for the EBA to clarify that exemptions are optional and not mandatory. As fraud patterns change, PSPs should be given the opportunity to apply strong customer authentication, as and when they deem appropriate, which should also be applicable for low value payments.
Therefore, we would request that the EBA consider changing the mandatory requirement of Article 8 of the RTS to a discretionary requirement, by substituting ‘may be’ for ‘is’ in the first line of Article 8 (1) and Article 8 (2).
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?
Yes, subject to clarification, per below.Article 12 of the RTS allows a servicing PSP other than the issuing PSP to utilise the Personalised Security Credentials of the issuing ASPSP to link the user to Personal Security Credentials of the AIPSP or acquiring PISP. This is sensible, as both AIPSP and PISP should be able to rely on the ASPSP’s authentication measures and Personal Security Credentials in order to create their own Personal Security Measures, which should, subject to compliance with this RTS, be treated as equivalent.
Article 14 and 16 could be augmented with guidance as to the minimum frequency of renewal of the AIPSP and PISP personal security credentials (eg at least annually), as the text refers to the period of review of the associated procedures rather than the period between issue or renewal.
Article 16 could also be subject to a risk based approach for re-issue of personalised security credentials, in conjunction with a regular (minimum) periodic renewal.
We note that both PayPal and iSignthis have automated and remote means to verify ownership of a payment instrument, perform customer due diligence and link these to their own personalized security credentials. Both PayPal and iSignthis rely upon the “……use of the users personalised security credentials” as provided by the ASPSP, as part of their respective processes. Similarly, it is our understanding that Yodlee, an AIPSP, requires the use of the ASPSP personalised security credentials in the first instance, in order to link the PSU to Yodlee credentials for subsequent activities.
In the above cases, the PSU must “use” the issuing ASPSP’s personal security credentials in order to link a card or account to a further PSP’s service. Both PayPal and iSignthis achieve this by use of transmitting a secret to the PSU’s secure portal (eg their bank portal), and the PSU must retrieve the secret and confirm it to PayPal or iSignthis in order to link accounts from their existing PSP to a 3rd party PSP. Retrieval of the ‘secret’ requires “use” of the ASPSP’s personalised security credentials as part of the process.
The indirect identity payment instrument verification and authentication process used by PayPal and iSignthis has advantages in that it avoids Man in the middle, Boy in the browser, or security breach attacks, as may be the case via any exposed API with a third party user interface.
This indirect means ensures that the integrity of the issuing ASPSP’s security is not compromised by attack vectors that become available via direct API access. Whilst both companies have their own patented processes, their processes allow identification of a customer remotely, and subsequent issue of credentials via a range of physically and logically separated system.
All of the iSignthis, PayPal and Yodlee approaches allow for ‘one leg out’ authentication, where the ASPSP is outside the EU/SEPA, with the PISP being inside the SEPA. We note that both iSignthis and PayPal use an out of band method to authenticate by including the use of the users personal security credentials. The use of an out of band channel as part of an authentication process forms part of US FFIEC Guidance, as it mitigates against certain security threats, by layering security.
We note that the major card schemes have mandated EMVCo to develop next generation 3D Secure, incorporating 2FA and mobile features. EMVCO’s second generation 3D Secure incorporating 2FA is still as yet not released, and it will likely require significant investment by the ASPSP’s in order to comply with this RTS. Use of existing ASPSP personalised security credentials as part of the PISP process, either directly, indirectly or out of band, will provide industry with options.
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?
Yes, it is our submission a sensible balance has been struck.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?
Yes, and for the reasons suggested by the EBA; namely that this is the industry standard and thus should have the least burden on industry participants.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 ?
Yes, and for the reasons suggested by the EBA.However, in the event that no or only a limited number of qualified trust service providers were designated under e-IDAS, clearly a different approach will be needed.
We do not agree that a feasible alternative is to permit the use of website certificates issued by a general Certificate Authority.
Certificates are issued with sometimes only cursory due diligence by the Certificate Authority. Too much responsibility would need to be placed on the Certificate Authority to check that the applicant is registered, holds licenses, etc etc. Further, Certificate Authorities are often located outside the jurisdiction of the EBA.
In our submission, this would clearly require alternative processes to be adopted by ASPSPs to verify the registration number, despite the burden this places on them.
We note that even the Extended Validation (EV) certificate providers do not perform customer due diligence to the standard level required under the 4th AML Directive.
Extended Validation certificates are the highest class of SSL certificates available. EV SSL Certificates offer a stronger guarantee that the owner of the website passed a thorough, and globally standardized, identity verification process defined within the EV guidelines for SSL certificates.
The Extended Validation identity verification process requires the applicant to prove exclusive rights to use a domain, confirm its legal, operational and physical existence, and technically prove that the entity to which the certificate was issued has authorized the issuance of the Certificate. However, there is no check on the Company’s certified accreditations (eg ISO27001, PCI-DSS), directors, ultimate beneficial owners and so forth, or that the company is licensed to participate as a Payment Services Provider.
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.
As a matter of general principle we see no reason why an AISP should be querying data when the user is offline or not using the AISP. Data requests should be made in real time, and based on a session initiated and requested by the account holder.Dormancy is also an issue, as a user may cease practical use of a service, but may not deactivate an account with AISP for some time. Under such scenario, we see the introduction of unnecessary risks due to data transport and distribution of sensitive data, with no corresponding benefit to AISP, PSP or end user.