Response to discussion on RTS on strong customer authentication and secure communication under PSD2
Go back
¥ Wallets & On-boarding (remote KYC). It is within the scope of our experience that many e-wallets and m-wallets do not adhere to the requirements for customer identification via a conformant customer due diligence process when on-boarding new customers. In particular, this is an issue for wallets who allow customers to choose to fund wallets via cards, where wallets are funded not only as a stored value facility, but in particular as a checkout/payment gateway facility providing instant payment from a stored card to a merchant. Mobile Wallets (card on-boarding & KYC), including some very large brands, presently do not consistently on-board customers, or perform customer due diligence. The “green” path used by Apple to on-board customers has been shown to be susceptible to fraud. The call centre approach used in the US, whilst slow and cumbersome, still relies entirely upon the issuer, with Apple taking no proactive measures to secure their ecosystem. All wallets should be required to conform to the ‘Security of Internet Payments’ whereby cards must be authenticated during the on-boarding process.
¥ Card on-boarding to card vaulting or card storage facilities with PSP payments utilising tokenization. Presently, many PSPs store card Primary Account Numbers (PANs) on behalf of merchants. Merchant’s can ‘call off’ these PANs using a pre-agreed token. In theory this is a more secure process as the PAN is not exposed via transmission. In our submission, cards should be authenticated by the card holder at on-boarding, before being stored in such a tokenization system. We also posit that the intent of the PSD2 requirements would require all future payments that are not subject to exemptions for a particular transaction to be individually authenticated.
¥ First generation 3D Secure implementations (the 1FA versions). By definition, single factor authentication is not in conformity with the PSD2 requirements.
¥ Risk based 3D Secure systems. Such systems are based on predictive analytics, relying on de-personalised, historic pattern analysis. Such systems may be useful in risk based assessments, such as for payments below the threshold in PSD2. Where such systems are used for transactions above the lower payment threshold specified in the PSD2, they do not actually authenticate that the user initiated the payment, but rather give a probability of such. In our submission, a probability analysis is a risk based analysis and does not constitute evidence, and is thus not what is required by PSD2.
¥ eMandates (electronic authority), which still rely on manual processing of the authority. As volumes increase, such systems may be susceptible to error or fraud.
¥ Recurring payments. Payments for ongoing subscriptions has not in our submission been addressed. It would be helpful if specific guidance was given on how recurring payments should be authenticated for subscription payments. This could address, issues such as whether strong customer authentication be required each month and whether the overall total should be subject to strong customer authentication upfront.
¥ Payments from outside the SEPA for non SEPA issued cards. On the basis that one leg out authentication is technically feasible today, we posit that it should be implemented to mitigate fraud and AML/CTF risks. PayPal and iSignthis have this capability today, as might others.
By way of background we note that we identify four commercial means to verify card ownership for remote on-boarding being; the PayPal method; the iSignthis method; 3D Secure process; and manual call centre/face-to-face method.
¥ PayPal and iSignthis utilize dynamic knowledge based authentication, inserting a one-time secret into the secure environment of a PSU’s transaction statement. The PSU must utilize their personalized security credentials to access the ‘secret’ and by doing so they prove they own the account underlying the remote payment instrument. Importantly, these means do not require the PSU to disclose their personalized security credentials to a third party in order to retrieve the secret.
¥ By contrast, 3D Secure often uses static knowledge based authentication to link a card to its (at present) 1FA solutions, whereby card data, name and date of birth are the most common ‘challenges’ presenting for online activation. In our submission, a dynamic means should be a requirement, as static based approaches are prone to fraud leading to impersonation risk.
¥ Call centres and face-to-face approaches are open to human error, but should be preferred to static based approaches.
The ‘secret’ created by either the iSignthis or PayPal process, which must be retrieved by the PSU after accessing their transactional statement via their issuing PSP’s portals is an example of a data possession element. These data possession elements, are secure because the element is in the form of information or data, which only the PSU will have the ability to access via the issuer.
In answer to question 11, we expand further, but we also note that loss of a mobile device could allow access to possession elements of strong customer authentication, particularly if device does not have screen lock active. A mobile device by itself is therefore, in our submission, not an appropriate example of a possession element in the context of strong customer authentication.
¥ Repeat delivery of goods to same address from same vendor (be it physical or digital), with value of goods less than a pre-agreed threshold limit could be taken as inherence. We believe that this could be limited by a pre-agreed limit, subject to strong customer authentication, and only valid for a maximum duration (say 12 months), and a pre-agreed and fixed delivery address(es).
¥ Subscription or recurring related transactions, could also be taken as inherence. This could be subject to the first transaction amount being authenticated together, with the recurring frequency (weekly/monthly) and total period (say 6 or 12 months).
We note that this will be a relatively familiar process to many on-line merchants and other actors in the payment card industry, as these are similar to the basis on which the card scheme rules allow a merchant to prove a disputed on-line transaction.
Accessing a mobile provides access to both the TCP/IP channels and the GSM channels. For mobile on-line commerce this may be an insurmountable issue in the context of the independence of authentication elements.
For 2FA, one factor might be a dynamic one-time code, transmitted via SMS. It is doubtful if in such a case that a second factor intrinsically connected with the mobile device (eg, finger print authentication) could be consider a truly independent element.
Further, human and technological limitations may mean the dynamic one-time code appears ‘in the clear’ on an unlocked phone. In some case, 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.
¥ In our discussions with on-line merchants and PSPs, verification of the PSU’s true ownership of a payment Instrument is weak or non-existent in remote customer on-boarding. Many merchants’ verification in fact goes to AML KYC, but then makes no connection with the payment instrument. Even if the customer is correctly identified via static, historic data, and a dynamic link is made via a one-time SMS code, no genuine link is made of that PSU to the payment instrument. A genuine individual can therefore use another PSU’s credit card without being detected at the point of sale.
¥ Of course, the limitations of static, historic data mean that it is becoming easier over time to know the information required to impersonate another person in a remote customer on-boarding. For example, a person who has possession of a PSU’s lost or stolen wallet and mobile device
¥ Proprietary systems such as 3D Secure that do not allow third party authentication application access (via an API) consistent with the PSD2.
¥ Legacy 3D Secure systems that use weak historic knowledge based authentication to identify a customer (often using only card number, surname and date of birth).
¥ PayPal, which has verification of payment instrument, which can accommodate a 2FA.
¥ iSignthis, which has a strong customer authentication service, which includes 2FA.
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.
In our submission it is unclear from Paragraph 40 if liability will be on the payer’s PSP, or on the payee’s PSP, if the payer's PSP chooses not to implement strong customer authentication. It would be helpful if this was addressed in the draft RTS.
In the alternative case, where the acquiring PSP does not implement strong customer authentication, then the acquiring PSP is clearly liable. It is unclear whether this liability can be contracted out to the merchant. We would submit that the EBA should take the position that if the acquiring PSP does not support strong customer authentication, then it cannot contract out the liability to merchants. It is understood that if a merchant does not implement strong customer authentication, then it is liable for fraud, consistent with the current contractual arrangements.
A general comment is that for evidentiary purposes, the use of customer specific data, as opposed to depersonalised historic trend data, provides not only a higher level of confidence, but also a legal basis upon which to determine if fraud (3rd party or 1st party ‘friendly fraud’) has occurred. We note that:
• When implementing Items 42 B), C) and D) the customer is always known (or able to be subsequently identified) by all PSP parties in the payment chain, as authentication will need to have taken place at commencement.
• Whereas Item 42 A) the customer might be known, based upon transaction history, and if the payment instrument has previously been subject to strong customer authentication by the payer.
• With Item 42 E the customer will not be known, as it is defined as non sensitive data. In any event, privacy law will likely prohibit sensitive data and personally identifiable information being passed to the consultant, and back to a third or fourth party which was not the payer’s PSP.
Under Item 42 A) low value generally corresponds to low risk, so strong customer authentication is not necessary in our view for all low value payments. Where there is no indication that there is increased risk due to environmental factors, this would allow small payments to be made quickly (eg parking, music, movies, software/apps etc), and is limited to a daily threshold in any case. Environmental factors may include payment velocity, cardholder IP address outside the SEPA, or other factors commonly adopted by merchants.
The requirement for strong customer authentication for higher risk payments that are of low value may be a consideration, rather than use of a waiver based on (relatively) static, historic, trend data. We do not advocate static approaches be used at any time, as they are susceptible to fraud. Payments under the low value threshold can have a risk threshold determined dynamically using a combination of IP address or Issuer Identification Number (IIN) (to determine country) and frequency (velocity). All of these are simple acquiring (or issuing side) mechanisms, likely already implemented even at a medium size merchant level and above. If a payment request originates from outside the EU, then acquiring side strong customer authentication that indirectly incorporates issuer’s security, such as iSignthis, could be applied to safeguard against Fraud and Anti Money Laundering.
Item 42 E) appears to be inconsistent with the spirit and intent of the PSD2. This is because it does not identify and/or authenticate the customer, nor does it represent any advantage in low risk scenarios of 42A), except perhaps for ‘after the fact’ analysis. De-personalised data has no evidentiary value, and would at best only establish coincidence.
¥ Within the exception of 42 A) ‘low payments’, it is our position that the specific exceptions used as an example should only be applied after at least an initial and successful strong customer authentication process has been completed by the PSU at each particular merchant. ‘Typical’ behavior should be actually established by the PSU and should be subject to a minimum elapsed time between transactions period (say days or weeks) and should be subject to annual strong customer authentication revalidation. This is to avoid criminals (by manual or automated means) establishing ‘typical’ behavior patterns over a short period of time and exploiting the payment instrument across multiple merchants.
¥ Similarly, transaction attempts should be rate limited when in the low value range, to avoid automated attacks by way of repeated requests on payment systems leading to denial of service. Repetition velocity could be calculated upon the Primary Account Number of the card or IP address or both.
¥ It appears the only defence a merchant has against a payer acting fraudulently will come from either strong customer authentication or personalised transaction monitoring, in order to provide irrefutable or compelling evidence respectively that the payer did initiate the transaction. We posit that de-personalised methods are of no use for proving fraud and effecting liability shift, as privacy law would likely restrict any form of personally identifiable data to be shared, even if it was captured. We do not support the guidance encouraging the use of depersonalized approaches, as we posit that fraud will migrate to PSPs where this is used, and, it is contrary to the spirit of the PSD2 which seeks to mitigate fraud by identifying the customer.
¥ Under the assumption that the payer’s PSP may implement personalised transaction monitoring, it is unclear if the payer’s PSP will (or in fact can) share such data with the acquirer and merchant, even if fraud is suspected. This in turn leaves the merchant exposed despite such a high level of investment in security infrastructure under the PSD2. We posit that the personalized transaction monitoring should be on the acquiring or payee’s side, similar to AML/CTF remote customer due diligence approaches and transaction monitoring. The payer can then be presented with compelling or irrefutable evidence as to whether the payer did in fact execute the payment instruction, thus removing conflict of interest from the payers PSP which represents the payer’s interests (and not the payee’s). The major card schemes already have rules that support this process.
The ESA’s Draft Guidelines on Risk Factors per should be incorporated by reference with regards to identity proofing via customer due diligence process, with the section on e-money institutions being particularly relevant.
It is within the scope of our experience that many e-wallets and m-wallets do not adhere to the requirements for customer identification when on-boarding new customers. In particular, this is an issue for customers who choose to fund wallets via cards not only as a stored value facility, but in particular as a checkout /payment gateway facility providing instant payment from a stored card to a merchant.
The personal security credentials issued by the wallet operator should be subject to adequate customer due diligence.
For example, on the one device we may have:
¥ An IP channel; where the browser stores the static password (or first factor).
¥ A GSM Channel; where an SMS is received via this channel (usually the second factor)
¥ An App Channel/IP; wherein an app acts as an authenticator. Some apps, such as Azure Authenticator, can remain “logged in” and do not require active login.
In all of the above cases, loss of a mobile device would allow access to both static and dynamic (or possession) elements of strong customer authentication, particularly if device does not have screen lock active.
Both PayPal and iSignthis have automated and remote means to verify ownership of a payment instrument, perform customer due diligence and link these to personalized security credentials.
In both cases, the PSU must utilize the issuing institution’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.
This indirect identity payment instrument verification and authentication process 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 PSP’s security is uncompromised by attack vectors using API. 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.
These parties should be subject to third party certification, and perhaps random audit by regulators, to ensure that they comply with requirements. At the very least certified as to their technologies and security practices.
Registration should include a submission with regards to the processes, management structure and corporate structure, on a similar basis to a payment institution. AISP’s and their staff will have access to confidential information of the PSU, and a third party certification program such as the Payment Card Industry (PCI) has in place for cards should be implemented for AISP account access.
All requirements should be technology and method neutral, stipulating only desired outcomes and not the means to achieve them. The guidance may provide examples, but we do not consider that the examples should be mandatory.
A federated trust or single sign on approach for log in by AIS/PIS/ASPSP exposes a common point for failure, breach and attack and should be avoided.
It also means that PSU’s could lose visibility of which AIS/PIS is actually accessing its services.
A trusted third part may be used in addition to the individual AIS/PIS credentials.
The AIS/PSP can then issue its own credentials, and use tokenization to link to the PSU’s account with the PSP.
No, if eIDAS considered as the principal solution. This is because:
¥ eIDAS has no means to dynamically enrol a customer during a purchase, and largely requires a complex enrolment process for the individual.
¥ For mass acceptance by merchants, mass rollout of eIDAS would be required in advance, which would be slow, and lead to delays in securing payments in the interim.
¥ Payment Service providers would need to integrate to eIDAS servers.
¥ Mass scale/volume eIDAS authentication servers would need to be rolled out.
¥ New or replacement payment instruments would need to be subsequently linked, with facilities provided by either issuer, trust agency or government.
¥ Transients, tourists and immigrants would not have an eIDAS or easy access.
¥ Export sales (or monetary inflows to EU) would still be exposed to AML/CTF and fraud issues.
¥ eIDAS does not directly support the ECB’s ‘one leg out’ policy objective.
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.
From our experience, a wide range of common industry transactions imply a risk of payment fraud. In our view the risk involved are either not being properly understood or in some cases not being properly considered. Some further examples include:¥ Wallets & On-boarding (remote KYC). It is within the scope of our experience that many e-wallets and m-wallets do not adhere to the requirements for customer identification via a conformant customer due diligence process when on-boarding new customers. In particular, this is an issue for wallets who allow customers to choose to fund wallets via cards, where wallets are funded not only as a stored value facility, but in particular as a checkout/payment gateway facility providing instant payment from a stored card to a merchant. Mobile Wallets (card on-boarding & KYC), including some very large brands, presently do not consistently on-board customers, or perform customer due diligence. The “green” path used by Apple to on-board customers has been shown to be susceptible to fraud. The call centre approach used in the US, whilst slow and cumbersome, still relies entirely upon the issuer, with Apple taking no proactive measures to secure their ecosystem. All wallets should be required to conform to the ‘Security of Internet Payments’ whereby cards must be authenticated during the on-boarding process.
¥ Card on-boarding to card vaulting or card storage facilities with PSP payments utilising tokenization. Presently, many PSPs store card Primary Account Numbers (PANs) on behalf of merchants. Merchant’s can ‘call off’ these PANs using a pre-agreed token. In theory this is a more secure process as the PAN is not exposed via transmission. In our submission, cards should be authenticated by the card holder at on-boarding, before being stored in such a tokenization system. We also posit that the intent of the PSD2 requirements would require all future payments that are not subject to exemptions for a particular transaction to be individually authenticated.
¥ First generation 3D Secure implementations (the 1FA versions). By definition, single factor authentication is not in conformity with the PSD2 requirements.
¥ Risk based 3D Secure systems. Such systems are based on predictive analytics, relying on de-personalised, historic pattern analysis. Such systems may be useful in risk based assessments, such as for payments below the threshold in PSD2. Where such systems are used for transactions above the lower payment threshold specified in the PSD2, they do not actually authenticate that the user initiated the payment, but rather give a probability of such. In our submission, a probability analysis is a risk based analysis and does not constitute evidence, and is thus not what is required by PSD2.
¥ eMandates (electronic authority), which still rely on manual processing of the authority. As volumes increase, such systems may be susceptible to error or fraud.
¥ Recurring payments. Payments for ongoing subscriptions has not in our submission been addressed. It would be helpful if specific guidance was given on how recurring payments should be authenticated for subscription payments. This could address, issues such as whether strong customer authentication be required each month and whether the overall total should be subject to strong customer authentication upfront.
¥ Payments from outside the SEPA for non SEPA issued cards. On the basis that one leg out authentication is technically feasible today, we posit that it should be implemented to mitigate fraud and AML/CTF risks. PayPal and iSignthis have this capability today, as might others.
By way of background we note that we identify four commercial means to verify card ownership for remote on-boarding being; the PayPal method; the iSignthis method; 3D Secure process; and manual call centre/face-to-face method.
¥ PayPal and iSignthis utilize dynamic knowledge based authentication, inserting a one-time secret into the secure environment of a PSU’s transaction statement. The PSU must utilize their personalized security credentials to access the ‘secret’ and by doing so they prove they own the account underlying the remote payment instrument. Importantly, these means do not require the PSU to disclose their personalized security credentials to a third party in order to retrieve the secret.
¥ By contrast, 3D Secure often uses static knowledge based authentication to link a card to its (at present) 1FA solutions, whereby card data, name and date of birth are the most common ‘challenges’ presenting for online activation. In our submission, a dynamic means should be a requirement, as static based approaches are prone to fraud leading to impersonation risk.
¥ Call centres and face-to-face approaches are open to human error, but should be preferred to static based approaches.
2. Which examples of possession elements do you consider as appropriate to be used in the context of strong customer authentication, must these have a physical form or can they be data? If so, can you provide details on how it can be ensured that these data can only be controlled by the PSU?
In our submission, a possession element need not be physical, but could be data. Indeed, a data element can be more secure as it can be on-time and time-limited.The ‘secret’ created by either the iSignthis or PayPal process, which must be retrieved by the PSU after accessing their transactional statement via their issuing PSP’s portals is an example of a data possession element. These data possession elements, are secure because the element is in the form of information or data, which only the PSU will have the ability to access via the issuer.
In answer to question 11, we expand further, but we also note that loss of a mobile device could allow access to possession elements of strong customer authentication, particularly if device does not have screen lock active. A mobile device by itself is therefore, in our submission, not an appropriate example of a possession element in the context of strong customer authentication.
3. Do you consider that in the context of “inherence” elements, behaviour-based characteristics are appropriate to be used in the context of strong customer authentication? If so, can you specify under which conditions?
We concur that there are behaviour-based characteristics which could be appropriate and indeed useful in the context of strong customer authentication. For example, we posit that:¥ Repeat delivery of goods to same address from same vendor (be it physical or digital), with value of goods less than a pre-agreed threshold limit could be taken as inherence. We believe that this could be limited by a pre-agreed limit, subject to strong customer authentication, and only valid for a maximum duration (say 12 months), and a pre-agreed and fixed delivery address(es).
¥ Subscription or recurring related transactions, could also be taken as inherence. This could be subject to the first transaction amount being authenticated together, with the recurring frequency (weekly/monthly) and total period (say 6 or 12 months).
We note that this will be a relatively familiar process to many on-line merchants and other actors in the payment card industry, as these are similar to the basis on which the card scheme rules allow a merchant to prove a disputed on-line transaction.
4. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to the independence of the authentication elements used (e.g. for mobile devices)?
We consider that technological and human factors present challenges for the independence of elements for strong customer authentication.Accessing a mobile provides access to both the TCP/IP channels and the GSM channels. For mobile on-line commerce this may be an insurmountable issue in the context of the independence of authentication elements.
For 2FA, one factor might be a dynamic one-time code, transmitted via SMS. It is doubtful if in such a case that a second factor intrinsically connected with the mobile device (eg, finger print authentication) could be consider a truly independent element.
Further, human and technological limitations may mean the dynamic one-time code appears ‘in the clear’ on an unlocked phone. In some case, 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.
5. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to dynamic linking?
We have identified four examples that we consider present such challenges:¥ In our discussions with on-line merchants and PSPs, verification of the PSU’s true ownership of a payment Instrument is weak or non-existent in remote customer on-boarding. Many merchants’ verification in fact goes to AML KYC, but then makes no connection with the payment instrument. Even if the customer is correctly identified via static, historic data, and a dynamic link is made via a one-time SMS code, no genuine link is made of that PSU to the payment instrument. A genuine individual can therefore use another PSU’s credit card without being detected at the point of sale.
¥ Of course, the limitations of static, historic data mean that it is becoming easier over time to know the information required to impersonate another person in a remote customer on-boarding. For example, a person who has possession of a PSU’s lost or stolen wallet and mobile device
¥ Proprietary systems such as 3D Secure that do not allow third party authentication application access (via an API) consistent with the PSD2.
¥ Legacy 3D Secure systems that use weak historic knowledge based authentication to identify a customer (often using only card number, surname and date of birth).
6. In your view, which solutions for mobile devices fulfil both the objective of independence and dynamic linking already today?
To our knowledge, only two solutions are available that would fulfil both the objective of independence and dynamic linking. These are:¥ PayPal, which has verification of payment instrument, which can accommodate a 2FA.
¥ iSignthis, which has a strong customer authentication service, which includes 2FA.
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.
7. Do you consider the clarifications suggested regarding the potential exemptions to strong customer authentication, to be useful?
Yes, guidance of this form is particularly useful. In elaboration of this, we make the following more specific submissions.In our submission it is unclear from Paragraph 40 if liability will be on the payer’s PSP, or on the payee’s PSP, if the payer's PSP chooses not to implement strong customer authentication. It would be helpful if this was addressed in the draft RTS.
In the alternative case, where the acquiring PSP does not implement strong customer authentication, then the acquiring PSP is clearly liable. It is unclear whether this liability can be contracted out to the merchant. We would submit that the EBA should take the position that if the acquiring PSP does not support strong customer authentication, then it cannot contract out the liability to merchants. It is understood that if a merchant does not implement strong customer authentication, then it is liable for fraud, consistent with the current contractual arrangements.
A general comment is that for evidentiary purposes, the use of customer specific data, as opposed to depersonalised historic trend data, provides not only a higher level of confidence, but also a legal basis upon which to determine if fraud (3rd party or 1st party ‘friendly fraud’) has occurred. We note that:
• When implementing Items 42 B), C) and D) the customer is always known (or able to be subsequently identified) by all PSP parties in the payment chain, as authentication will need to have taken place at commencement.
• Whereas Item 42 A) the customer might be known, based upon transaction history, and if the payment instrument has previously been subject to strong customer authentication by the payer.
• With Item 42 E the customer will not be known, as it is defined as non sensitive data. In any event, privacy law will likely prohibit sensitive data and personally identifiable information being passed to the consultant, and back to a third or fourth party which was not the payer’s PSP.
Under Item 42 A) low value generally corresponds to low risk, so strong customer authentication is not necessary in our view for all low value payments. Where there is no indication that there is increased risk due to environmental factors, this would allow small payments to be made quickly (eg parking, music, movies, software/apps etc), and is limited to a daily threshold in any case. Environmental factors may include payment velocity, cardholder IP address outside the SEPA, or other factors commonly adopted by merchants.
The requirement for strong customer authentication for higher risk payments that are of low value may be a consideration, rather than use of a waiver based on (relatively) static, historic, trend data. We do not advocate static approaches be used at any time, as they are susceptible to fraud. Payments under the low value threshold can have a risk threshold determined dynamically using a combination of IP address or Issuer Identification Number (IIN) (to determine country) and frequency (velocity). All of these are simple acquiring (or issuing side) mechanisms, likely already implemented even at a medium size merchant level and above. If a payment request originates from outside the EU, then acquiring side strong customer authentication that indirectly incorporates issuer’s security, such as iSignthis, could be applied to safeguard against Fraud and Anti Money Laundering.
Item 42 E) appears to be inconsistent with the spirit and intent of the PSD2. This is because it does not identify and/or authenticate the customer, nor does it represent any advantage in low risk scenarios of 42A), except perhaps for ‘after the fact’ analysis. De-personalised data has no evidentiary value, and would at best only establish coincidence.
8. Are there any other factors the EBA should consider when deciding on the exemptions applicable to the forthcoming regulatory technical standards?
We consider that there are a number of factors that would make useful examples, either as such or on which the the Draft RTS could set out useful guidance:¥ Within the exception of 42 A) ‘low payments’, it is our position that the specific exceptions used as an example should only be applied after at least an initial and successful strong customer authentication process has been completed by the PSU at each particular merchant. ‘Typical’ behavior should be actually established by the PSU and should be subject to a minimum elapsed time between transactions period (say days or weeks) and should be subject to annual strong customer authentication revalidation. This is to avoid criminals (by manual or automated means) establishing ‘typical’ behavior patterns over a short period of time and exploiting the payment instrument across multiple merchants.
¥ Similarly, transaction attempts should be rate limited when in the low value range, to avoid automated attacks by way of repeated requests on payment systems leading to denial of service. Repetition velocity could be calculated upon the Primary Account Number of the card or IP address or both.
¥ It appears the only defence a merchant has against a payer acting fraudulently will come from either strong customer authentication or personalised transaction monitoring, in order to provide irrefutable or compelling evidence respectively that the payer did initiate the transaction. We posit that de-personalised methods are of no use for proving fraud and effecting liability shift, as privacy law would likely restrict any form of personally identifiable data to be shared, even if it was captured. We do not support the guidance encouraging the use of depersonalized approaches, as we posit that fraud will migrate to PSPs where this is used, and, it is contrary to the spirit of the PSD2 which seeks to mitigate fraud by identifying the customer.
¥ Under the assumption that the payer’s PSP may implement personalised transaction monitoring, it is unclear if the payer’s PSP will (or in fact can) share such data with the acquirer and merchant, even if fraud is suspected. This in turn leaves the merchant exposed despite such a high level of investment in security infrastructure under the PSD2. We posit that the personalized transaction monitoring should be on the acquiring or payee’s side, similar to AML/CTF remote customer due diligence approaches and transaction monitoring. The payer can then be presented with compelling or irrefutable evidence as to whether the payer did in fact execute the payment instruction, thus removing conflict of interest from the payers PSP which represents the payer’s interests (and not the payee’s). The major card schemes already have rules that support this process.
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?
Automated Customer Due Diligence processes used by eMoney insti/tutions where the payment instrument is integral to the due diligence process could provide the basis for a waiver. For example, PayPal’s Payment Instrument Verification process or iSignthis’ Payment Instrument Verification process, or equivalents. This would foster innovation, as evidenced by both entities having patented their solutions and the organization since exploiting them commercially whilst meeting AML/CTF requirements.10. Do you consider the clarification suggested regarding the protection of users personalised security credentials to be useful?
Yes, however the integrity of the system is predicated upon the correct person being identified in the first instance, prior to issue of the credentials. Even the most secure means of securing the credentials is of little consequence if identity proofing fails or has not been conducted properly.The ESA’s Draft Guidelines on Risk Factors per should be incorporated by reference with regards to identity proofing via customer due diligence process, with the section on e-money institutions being particularly relevant.
It is within the scope of our experience that many e-wallets and m-wallets do not adhere to the requirements for customer identification when on-boarding new customers. In particular, this is an issue for customers who choose to fund wallets via cards not only as a stored value facility, but in particular as a checkout /payment gateway facility providing instant payment from a stored card to a merchant.
The personal security credentials issued by the wallet operator should be subject to adequate customer due diligence.
11. What other risks with regard to the protection of users’ personalised security credentials do you identify?
The use of smartphone/tablet device acting as payment device with no separation of authentication ‘channels’ poses such a risk. Mobile devices typically have both Internet Protocol and GSM Mobile channels, which are frequently used to transmit both static and dynamic authentication factors.For example, on the one device we may have:
¥ An IP channel; where the browser stores the static password (or first factor).
¥ A GSM Channel; where an SMS is received via this channel (usually the second factor)
¥ An App Channel/IP; wherein an app acts as an authenticator. Some apps, such as Azure Authenticator, can remain “logged in” and do not require active login.
In all of the above cases, loss of a mobile device would allow access to both static and dynamic (or possession) elements of strong customer authentication, particularly if device does not have screen lock active.
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?
Yes.Both PayPal and iSignthis have automated and remote means to verify ownership of a payment instrument, perform customer due diligence and link these to personalized security credentials.
In both cases, the PSU must utilize the issuing institution’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.
This indirect identity payment instrument verification and authentication process 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 PSP’s security is uncompromised by attack vectors using API. 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.
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?
No.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?
In our submission this is the API access via AISP to PSP’s. Parties that are only registered and not subject to full regulatory oversight, including AML/CTF and PSD2 regulation represent the highest risk.These parties should be subject to third party certification, and perhaps random audit by regulators, to ensure that they comply with requirements. At the very least certified as to their technologies and security practices.
Registration should include a submission with regards to the processes, management structure and corporate structure, on a similar basis to a payment institution. AISP’s and their staff will have access to confidential information of the PSU, and a third party certification program such as the Payment Card Industry (PCI) has in place for cards should be implemented for AISP account access.
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?
Yes16. 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?
In our submission, the EBA should allow a means for innovations that do not conform to the present methods to be presented for review by an expert panel. Criteria could be set in advance for what would constitute a successful solution. These criteria should be performance and outcome based requirements, rather than prescriptive requirements.All requirements should be technology and method neutral, stipulating only desired outcomes and not the means to achieve them. The guidance may provide examples, but we do not consider that the examples should be mandatory.
17. In your opinion, is there any standards (existing or in development) outlining aspects that could be common and open, which would be especially suitable for the purpose of ensuring secure communications as well as for the appropriate identification of PSPs taking into consideration the privacy dimension?
No.18. How would these requirement for common and open standards need to be designed and maintained to ensure that these are able to securely integrate other innovative business models than the one explicitly mentioned under article 66 and 67 (e.g. issuing of own credentials by the AIS/PIS)?
In our submission, authentication requirements will need to be agreed and implemented on an individual PSP to individual ASPSP/AIS/PIS basis, ensuring that each is an independent link. This optimizes security entropy, and also ensures that the PSP has a register of AIS/PIS accessing its PSU’s.A federated trust or single sign on approach for log in by AIS/PIS/ASPSP exposes a common point for failure, breach and attack and should be avoided.
It also means that PSU’s could lose visibility of which AIS/PIS is actually accessing its services.
A trusted third part may be used in addition to the individual AIS/PIS credentials.
The AIS/PSP can then issue its own credentials, and use tokenization to link to the PSU’s account with the PSP.
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.
Yes, if used where eIDAS is available. However, this should require linking payment instruments directly to eIDAS at time of enrolment.No, if eIDAS considered as the principal solution. This is because:
¥ eIDAS has no means to dynamically enrol a customer during a purchase, and largely requires a complex enrolment process for the individual.
¥ For mass acceptance by merchants, mass rollout of eIDAS would be required in advance, which would be slow, and lead to delays in securing payments in the interim.
¥ Payment Service providers would need to integrate to eIDAS servers.
¥ Mass scale/volume eIDAS authentication servers would need to be rolled out.
¥ New or replacement payment instruments would need to be subsequently linked, with facilities provided by either issuer, trust agency or government.
¥ Transients, tourists and immigrants would not have an eIDAS or easy access.
¥ Export sales (or monetary inflows to EU) would still be exposed to AML/CTF and fraud issues.
¥ eIDAS does not directly support the ECB’s ‘one leg out’ policy objective.