With respect to Article 97(1) (c), we understand that the examples offered by EBA are enough to provide clarity.
CyberSource considers that we must strike a balance between security and convenience. We must therefore be flexible when considering possession elements with the aim of improving merchant sales. Increasing the friction at checkout by introducing strong customer authentication may impact the number of orders that merchants are able to convert to sales.
Possession elements can have either a physical form or they can be data. A good example of a possession element could be the mobile device fingerprint, which is created from a variety of data that is compiled from the PSU’s mobile device after they grant access. A mobile device is typically only controlled by the PSU, as it is portable and can be carried anywhere (unlike, for example, a desktop). Another example would be an application on the device which generates random numbers.
We consider that “inherence” elements should be used in the context of strong customer authentication. There are many merchants that are currently using behaviour patterns to determine when a transaction could be fraudulent, with a high degree of success. PSUs can display buying patterns that match previous orders (the device used, IP address, goods or services bought, delivery address, departure airport, etc.). When a current order matches previous purchases, the merchant can infer that it is the PSU making the transaction. When there are variations in the buying patterns, there could be an additional layer of security to confirm that it is the PSU.
However, given that there are multiple variations depending on the goods/services sold and the industry the merchant belongs to, we consider the EBA should not provide a closed list of elements that it considers suitable for “inherence”.
CyberSource has a product called Decision Manager that allows a merchant to screen orders for fraud. The merchant sends additional behavioural information on the order, such as IP address, goods or services bought, delivery address, etc. to the Decision Manager platform. This platform then calculates a risk score that can be increased or decreased by the merchant based on their knowledge of the business. For example, if the PSU has purchased several times at the merchant without any fraud problem, the merchant may decide to reduce the risk associated to the transaction. If, on the contrary, the PSU is a new customer, purchasing a large amount of goods that the merchant associates with fraud, then the merchant may decide to increase the risk associated with the transaction. The score will then enable the merchant to determine whether to accept, reject or send the transaction to one of its customer service agents to review manually.
The use of one-time passwords (“OTPs”) sent to mobile devices may compromise the independence of the authentication elements used. However, this would only result in the “possession” element being compromised (in the case of theft of the device, for example). This compromise might be overcome with either of the other two elements, “knowledge” or “inherence”. The use of data tools such as Decision Manager, for example, help merchants identify when a device might have been compromised, by using additional information to make a decision. The buying patterns of fraudsters will not match the buying patterns of the genuine PSU.
We consider that the main challenge for fulfilling the objectives of strong customer authentication is that the solutions that are based on the RTS should be consumer-friendly, so that when they are implemented in the marketplace they do not prevent customers making legitimate purchases conveniently or penalise sales from merchants. For instance, a customer may not have a mobile device immediately to hand for the purpose of receiving OTPs. Customers might also compromise the independence of authentication elements in order to improve convenience; or otherwise limit or stop shopping via remote/cross-border channels.
The circumstances of a transaction may vary between the moment when authentication is requested and delivery. There may be goods that are not available when the order is due to be shipped; or the customer may have agreed to allow the substitution of items. In a grocery sales scenario, for example, some goods may be of variable weight, so the final amount of the order may not be known when authentication takes place.
There are already data elements within 3-D Secure transactions that allow for the integrity of the transaction, without the need to include dynamic linking to a specific amount.
Any solution that uses additional behavioural information in relation to transactions and which is based on customer profiles (with customer consent, where necessary) fulfils the objective of independence and dynamic linking. In addition, the current data elements included within card transactions in 3-D Secure guarantee the integrity of the transaction.
We understand that the clarifications regarding exemptions to strong customer authentication are useful and help understanding the PSD2’s article (paragraph 42). However, we do not consider it necessary for the EBA to detail the kind of information and capabilities required in its future regulatory technical standards. There are several providers in the market that supply these kinds of services (CyberSource is one of them) and the way that each company approaches transaction risk analysis is different. Providing a fixed set of requirements could compromise the business model of any one of these service providers.
Merchants should be allowed to decide when to try to authenticate the PSU and when not. It may be that the issuer of the payment instrument has an underperforming system, in which case the merchant should be allowed to use an inherence element, such as behavioural data, as part of strong customer authentication as an alternative to making an authentication request to the issuer. It is our view that the card schemes rules and related contracts between card scheme participants already provide the allocation of liability between the different parties in a transaction (issuer or acquirer). The RTS should include sufficient flexibility to allow merchants to bear the risk of the transaction where authentication is deemed impracticable, without any impact on the PSU’s rights in the event that the transaction turns out to be fraudulent.
The use of smartphones for purchases should be considered for an exemption in the forthcoming regulatory technical standards. Although screens are getting bigger with each new model that is launched in the market, the number of transactions that are converted to sales experienced when using smartphones is lower than with other devices (desktops, tablets).
Another exemption the RTS should consider is one of the most successful order conversion tools in the market, storing card details on file (either by a merchant who complies with PCI DSS or by providers of ‘tokenisation’ services), so that it may be used for successive purchases. This is highly valuable for merchants that have returning customers, which are usually offered a simplified checkout. Strong customer authentication is usually required for the first transaction, but is not required for the subsequent transactions, as “inherence” would allow the merchant to determine whether the PSU is really a returning customer.
As mentioned in the response to question 7, we do not consider that there should be detailed or exhaustive list(s) of criteria included in the regulatory technical standards,
and each merchant/provider should be capable of developing their own specific criteria.