In formulating this response Vendorcom has consulted with payments professionals from across a broad range of organisations and European markets, including representatives from PSPs, ASPSPs, PIS providers, AIS providers, payees, other payment service providers and a number of our partner associations.
Amongst all of those consulted in putting together this response, there was complete agreement that the continual improvement of security across all forms of electronic transactions is vital, and that secure customer authentication is a key element in that. However, there was also a general consensus that as currently written, the RTS may include a number of unintended consequences and that in a couple of key areas; risk management and the requirement around having an independent or segregated channel, mobile application or device for the dynamic linking, the RTS may significantly negatively impact upon both innovation and security.
Some of the concerns raised, relating broadly to proprietorial solutions, have been omitted from this response document and left to the individual organisations to detail in their own responses, however, the below are areas of concern raised upon which those consulted concur:
Definition of ‘authentication code’
It is currently unclear as to what the EBA is referring to when using the term ‘authentication code’. Interpreted by some to equate to the term ‘authorisation code’ in relation to card payments, this immediately creates a disconnect with interbank payments made by ACH or RTGS where the term is much less applicable. On the other hand, the interpretation of many others has led to the conclusion that it very much fits for remote online payments, but is not appropriate, or even feasible, in the customer present card payment environment.
Further clarification as to the meaning of ‘authentication code’ is sought and a general point of concern raised about the seemingly one size fits all approach to electronic payments being taken by the EBA in the RTS, which belies the level of differentiation between the different payment types, particularly between card payments and online banking payment methods.
EBA’s approach to risk management and risk ownership
a) The card payments industry has a proven history in developing solutions to mitigate the risk of fraud, including but not limited to the implementation of both EMV Chip & PIN in the customer present space, 3D Secure in the customer not present space and the creation of standards bodies such as the PCI Security Standards Council, whose standards are then cascaded through the card schemes. EMV Chip & PIN has all but eliminated fraud from the customer present payments environment and paved the way for the innovations which now see consumers undertaking an ever growing number of contactless card-based payments and now increasingly, contactless mobile transactions. In each case, these fraud mitigation solutions have come from the industry itself and have resulted from collaboration between the different players and have been specific to the payments use case (e.g. customer/card present, customer/card not present). It stands to reason, therefore, that the EBA have an opportunity to learn from the experience that this industry sector already has in the creation of new security standards/methods. With this in mind, a look back at the initial implementation and then the evolution of 3D Secure strongly illustrates this point. Initial adoption of 3D Secure by both merchant and consumer alike was poor; shopping cart abandonment where 3D Secure was implemented soared; merchants with 3D Secure chose to turn it off at peak seasonal periods (e.g. Christmas) to avoid cart abandonment. What we then saw was a steady evolution where, based on solid behavioural profiling, 3D Secure was only required when consumers were initiating a transaction outside of their normal span of behaviour. The blanket application of 3D Secure has now all but disappeared from the consumer experience as merchants and acquirers alike have chosen to implement a more risk-based approach, authenticating customers in the background and thus achieving a commercially sensible balance between mitigating risk and ensuring a low friction consumer experience. The lesson here is that ensuring the strength of customer authentication does not always necessarily have to rely on the customer strongly authenticating themselves and provides strong evidence to support the commercial need for a risk based approach to when SCA is required, rather than it being mandated, except in the case of the specifically identified exemptions detailed in Chapter 2 of the RTS.
b) Following on from point a), both merchants and acquirers, as well as card issuers have access to significant volumes of consumer data which, combined with sophisticated behavioural-based modelling tools, enable them to judge, with a high degree of accuracy, whether a particular transaction is being made by a particular payer, irrespective of whether or not that transaction is above/below a mandated value threshold. In such circumstances, where this level of confidence in the origin of the transaction exists, it would not appear that the mandating of SCA meets the intention of the PSD2’s aim of ensuring an ‘appropriate level of security for consumers and Payment Service Providers, through the adoption of effective and risk-based requirements...and allowing for the development of user-friendly...means of payment.’ This is a prime example of where differentiation between the payment types is vital, as the multiple layers of security in card payments, differ from the online banking payment methods where the ASPSP and PISP are the primary authenticators. A proposal such as that under consideration by the Payment Strategy Forum under the auspices of the UK Payment Systems Regulator may be a relevant approach to establishing this risk-based authentication standard.
c) The intent of the PSD2 to ensure an ‘appropriate level of security’ can be further supported by requiring card issuers, acquirers and merchants alike to regularly demonstrate their competence in assessing risk, by requiring written statements of policy/procedure backed up by regular reporting of chargeback/fraud statistics and by requiring the party choosing not to implement SCA to bear the liability for any fraud. For many players in the payments space, this requirement will not be anything new as they are already closely monitored by the card schemes around key fraud based statistics.
It is, therefore, proposed that the EBA review their approach to risk management and risk ownership in relation to the requirements of strong customer authentication, to enable card issuers, acquirers and merchants alike to take a risk-based approach to its implementation and thus ensure that, where the data points to the transaction being valid, the consumer is not inconvenienced by the requirement to strongly authenticate and thus, the progress made towards secure, yet largely frictionless payments and the continued and desired growth of the digital economy are maintained.
EMV based customer present transactions – Chip & PIN, Contactless (both Card & Mobile based)
a) In Article 3.1, the EBA describe the characteristics of knowledge for the purposes of strong customer authentication as including ‘…length, complexity, expiration time and the use of non-repeatable characters….’ It is apparent from this description that the EBA is referring specifically to passwords rather than PIN codes and raises the question as to whether a four digit PIN number as currently used for EMV Chip & PIN transactions would satisfy the knowledge requirement of the RTS, given the short length, lack of complexity, indefinite period of validity and use of repeated numbers. Given the success of Chip & PIN in all but removing fraud from customer present point of sale transactions and how embedded it is across Western Europe, it would appear neither necessary or desirable to force change in this area and such change is likely to cause consumer confusion and frustration, even before the consideration of cost/time associated with the related technical changes it would necessitate at point of sale.
Chip & PIN would, at first glance, appear to be the embodiment of secure customer authentication, therefore we assume that the apparent exclusion of PIN as a valid form of knowledge, based on the wording of Article 3.1, is unintentional and suggest revision of the wording to make it clear that PIN is indeed a valid form of knowledge for the purposes of SCA.
b) A similar level of clarification as in a) above is sought as to the application of the requirements to contactless payments, both via card and mobile. Currently, upon reaching the 30 GBP / 30 Euro thresholds for contactless payments, the consumer would be forced to authenticate via a Chip & PIN transaction instead. Given the current definition in Article 3.1, this would appear to no longer be adequate; again we believe this to be an unintended consequence.
a) As currently written, there is considerable concern that the requirement in Article 2.2 (b) that ‘The channel, device or mobile application through which the information linking the transaction to a specific amount and a specific payee is displayed shall be independent or segregated from the channel, device or mobile application used for initiating the electronic payment transaction’ effectively precludes a number of already common behaviours. For example;
• someone is browsing for goods using their mobile phone, they make a purchase and a text is sent to that same mobile phone,
• a contactless mobile payment is initiated and a message then displayed on the screen of the same mobile device,
• a purchase is made via an app and a confirmation sent via Whatsapp/text
It is vital to the continual development of mobile as a payment device that the wording of this requirement be reviewed and adapted to ensure that payments of this nature are acceptable.
In particular, clarification is sought as to whether a potential conflict exists with 3DSecure 2.0 which, through the introduction of SDK, allows merchants to integrate the SDK into their App and complete the authentication inside the App.
Consideration should be given as to whether dynamic linking is suitable in all circumstances. For example, is it necessary to have dynamic linking where there is already an appropriate level of security, such as in an EMV based customer present environment or would it be more appropriate for it be applied only to remote transactions?
b) The question has been raised as to whether Article 2.2 sufficiently mitigates against the risk of a man in the middle attack. For example, malware could be used to change a transaction from £50 to recipient X to £500 to recipient Y, but the message the consumer receives would still read £50 to X, which they would then confirm, message may be sent to the consumer that confirms that they are paying £50 to X, meaning that the PSP would transfer the £500 to Y as a fully authenticated transaction. It may be necessary to consider further precautions to protect against the risk of creating an environment in which the fraudster is able to commit what is effectively fully authenticated fraud.
Consideration should be given to the need to invalidate certain knowledge/possession based credentials as valid authentication elements should they be compromised or potentially compromised or are in the public domain (e.g. Facebook). Consideration should also be given to the risk of systematic compromise.
a) Additional consideration is requested as to whether the exemptions in Chapter 2 are mandated or whether decisions as to their application are left in the hands of the card issuer, acquirer or merchant, for the same reasons as those mentioned in the answer to Question 1. Preference is stated in favour of allowing the aforementioned parties to adopt a risk-based approach to the application of these exemptions, acknowledging that not all payments carry the same risk and therefore for their not being mandated. Should the EBA reflect that a risk based approach to the application of SCA, as we propose they should in our answer to Question 1, then exemptions should be rendered unnecessary as all decisions regarding SCA will be based on the level of risk associated with the transaction.
b) Specifically exempting low value transactions, runs the risk of forcing fraud down into the micro-payment environment, particularly in the remote electronic payment transaction arena. There is a risk that by providing a cumulative total of 100 EUR, the EBA is effectively setting a value for stolen card details of 100 EUR. Exempting low value transactions in this way also belies the fraud vulnerability of low value transactions, such as in-app payments. PSPs should be in a position to review the risk of particular transaction types/merchant categories and make a decision on the applicability of SCA based on the risk identified. It should be noted that £1 transactions have long been an indicator that a fraudster is testing that a card is still live.
c) How will SCA apply in cases where non-EEA markets decide to not support it? Care must be taken to avoid a scenario where a visitor to Europe is not able to use their card in particular use cases because their non-EEA issuing bank does not support SCA. Consideration should be given as to the relative impact of putting in place an exemption for cards where issuers from other markets do not support SCA versus the financial impact of the loss of revenue; with due attention paid to the potential vulnerabilities/liabilities that such an exemption might open up.
d) In the event that a risk-based approach to the application of SCA, which would render exemptions irrelevant, is not favoured by the EBA, then a process should be put in place via which organisations can submit applications for new exemptions. The existence of such a process will be important to ensure continued innovation around security and customer authentication suitable to new payment methods coming to market and further advances in authentication solutions/capability, allowing for new exemptions where the level of trust in the security of a transaction is such that SCA is no longer needed to achieve the PSD2’s aim of ensuring ‘appropriate security’ and would add an unnecessary level of friction to the transaction.
As discussed in answer to Question 4 above, the effective mandating of the exemptions; removing any ability for PSPs to apply a risk-based approach suitable to the particular nature of the transaction, particularly as it applies to low value transactions, creates the real danger that fraudsters will focus their attention on these, potentially more vulnerable, transactions, especially given the growth rate of purchases of digital content. PSPs (and acquirers/merchants) should be in a position to review the particular transaction types/merchant categories and make a decision on the applicability of SCA based on the risk identified.
Additional clarification as to the precise meaning of ‘personalised security credentials’ is sought, however, in principle the reasoning appears sound.
Having a common and secure open standard of communication for the purpose of identification, notification and information is regarded as desirable. A common interface ensures that ASPSPs don’t create proprietary interfaces which would otherwise increase cost and complexity and would fail to deliver the desired impact in terms of competition that is the aim of the PSD2.
One particular area of concern that has been raised relates to the possibility that the messaging will, depending on application, still have scope for ‘optional fields’ that will be implemented differently by the various parties (ASPSPs) involved.
The suggestion appears to be that AISPs, PISPs, etc. will be able to connect directly to each ASPSP using these APIs. However, it is not clear how this will work in practice for PISPs in a card environment. Assuming the Card Issuers are ASPSPs, does this mean that PISPs would need to connect to each Issuer individually? There is scope for the authentication process to be sub-contracted, provided the relevant agreements are in place. Would this support a similar model to the current 3D Secure process, whereby a much smaller number of providers can offer 3D Secure as a service for the Issuers – thus removing the need for those Issuers to all have their own APIs?
The concern about the proliferation of entities providing APIs is whether this also means an exponential increase in the testing and approval activities. For example, under current arrangements for terminal transactions with Acquirers, as the interface to the Scheme networks, accreditation is required for several different merchants before any sort of generic approval is available, even if the terminal and submission mechanism is identical. Taking the same solution to another Acquirer requires a further set of merchant tests, even if a generic approval has already been granted by a different Acquirer. If any aspect of the routing differs, for example using ReD as opposed to SagePay, the approvals have to be done again irrespective of whether the Switch already has working interfaces to all of the Acquirers, and already handles the terminal for another Acquirer.
If the direct APIs are to be implemented, and the number of connections increases significantly, then some of modular accreditation is vital as it is not practical to expect end-to-end approvals for each entity and each method of routing to those entities.
One additional word of caution relates to the non-standard implementation of standards such as ISO8583 and ISO20022 which can effectively mean that the standard is very quickly no longer standard. This is something that is being addressed within the payments industry via the Common Global Implementation initiative and we would therefore suggest that the EBA have regard to and reference that initiative when addressing the key area of how best to manage and maintain the standards over time.
a) Careful consideration should be given to the disproportionate impact that mandating ISO20022 could have on particular industry sectors who currently operate according to ISO8583, such as the fuel sector and that, whilst wholesale payments currently operate under ISO20022, this is not the case across the board with regard to retail payments. Concern exists that the cost and speed of adoption of ISO20022 would be prohibitive and that work is already taking place to supersede ISO20022. Both the ATM and LINK networks also currently use ISO8583 protocols. We suggest the RTS needs to address circumstances where there needs to be an interface with legacy systems, review international adoption of ISO20022 and consideration should be given as to whether the timescales for adoption are realistic at a commercial level.
b) ISO20022’s provisions around XML mean that it is possible for existing format simply to be put into an XML packet; running the risk that the desired standardisation is not achieved.
c) Concern has been raised that the stipulating ISO20022 could be an innovation inhibitor given the requirement under XML that the full message structure always be used and the high costs associated with making changes to data fields e.g. date ranges. To prevent such inhibition of innovation, it is suggested that other messaging standards are also considered; those which, whilst complying with the content requirements of messages are less onerous to implement. It is also imperative that consideration is given to future proofing and that the messaging format will need to reflect whatever is prevalent at the time (provided it meets the agreed content requirements).
Certainly this would be one suitable option, however, relying on e-IDAS exclusively would not be appropriate, particularly as placing reliance on one party creates significant vulnerability across the whole infrastructure. For example, reviewing the work being undertaken by the MIDAS Alliance could also provide another option. Care should also be paid to the fact that payments is inextricably global and options considered should therefore be global in their application wherever possible.
There is a general consensus that this is a business decision for the individual ASPSPs. Under the new GDPRs, consumers will have to explicitly consent for their data to be used by the AISPs and to what it is used for, which may in itself have the effect of reducing the demand on the ASPSPs. There may also be a case for ASPSPs charging AIS providers for this service or providing a tiered system whereby, for example, AISPs could request information twice daily free of charge or could subscribe to a paid for service that allows, 5, 10, 15 etc. queries depending on the band of service they subscribe to. The income generated by ASPSPs could then be used to further improve the robustness of their communication interfaces? However, this remains, in our opinion, a business decision for the individual ASPSPs.
Business Community / Trade Association
Vendorcom Europe is a multi-stakeholder membership organisation that connects seekers, solvers and shapers in the European Payments Community. It has helped shape the collaborative/competitive landscape in payments since launching in 2003 and has developed its reputation over the past 13 years by establishing itself as Europe's definitive forum for keeping in touch with what's what and who's who in payments. It is the most trusted, independent forum for suppliers and users of payment systems in Europe.
Vendorcom is as single point of authoritative, credible, independent information and is the focal point for organisations who are part of, or want to engage with, the European Payments Community and are seeking to understand the dynamics of this diverse sector and its widespread national and regional variances.