Behavioural Biometrics

Many European Issuers are unclear on how to deliver a compelling customer experience given the recent clarifications to the EBA's guidance about what types of authentication would be considered compliant for the PSD-2's requirements for Strong Consumer Authentication.

The Regulatory Framework

EBA June 2019 Opinion

The EBA's June 2019 Opinion Paper has caused much consternation for eCommerce merchants and card issuers alike.

While it provides some useful clarity on what can, and more importantly, cannot be considered Possessive, Inherence and Knowledge elements. Paragraph 19 is a useful and comprehensive list of the 'biological' elements that are allowed be used as an inherence element.

19. Inherence may include retina and iris scanning, fingerprint scanning, vein recognition, face and hand geometry (identifying the shape of the user’s face/hand), voice recognition, keystroke dynamics (identifying a user by the way they type and swipe, sometimes referred to as typing and swiping patterns), the angle at which the PSU [payment service user, i.e. the consumer] holds the device and the PSU’s heart rate (uniquely identifying the PSU), provided that the implemented approaches provide a ‘very low probability of an unauthorised party being authenticated as the payer’, in accordance with Article 8 of the RTS on SCA and CSC.

Unfortunately, paragraph 21 then outlaws the use of data from a 3-D Secure transaction as the basis of a biometric inherence factor.

21. In addition, communication protocols such as EMV® 3-D Secure version 2.0 and newer would not currently appear to constitute inherence elements, as none of the data points, or their combination, exchanged through this communication tool appears to include information that relates to biological and behavioural biometrics (as mentioned in paragraph 18 above). That being said, if future data points exchanged via such protocols enabled the PSP to identify ‘something the PSU is’, in line with the examples provided in paragraph 19 above, such protocols might possibly be considered inherence elements in the future.

The UK FCA's Advice to CEOs

Furthermore, on 20 August the FCA issued a Letter to CEOs advising them of the 18 month implementation period while also re-iterating that banks had to implement a mode of SCA that did not disadvantage the vulnerable consumers.

Managing the impact on vulnerable or digitally excluded consumers
We also expect firms to manage the potential negative impact of SCA on different groups of customers, particularly the vulnerable, less digitally engaged or located in areas with limited digital access. We have been clear that firms may need to provide options for the methods of authentication. This includes taking into account that not all consumers will possess a mobile phone. So, we expect firms to provide a viable means of authenticating these customers.

The EBA's Reduction of the Implementation Period

On 16 October, the EBA published Opinion on the deadline for the migration to SCA which basically said that the ecosystem has had long enough to prepare for the application of SCA and an 18m phased implementation period - as had been proposed by the FCA and other national regulators - was too lax and the implementation period should conclude on 31 Dec 2020. In practical terms, given how ecommerce volumes spike in the run-up to the festival season, it would be a bold move for a merchant or an issuer to make a change of this magnitude during November & December; therefore, all merchants, acquirers and issuers should plan to be fully-compliant with the SCA requirements by the end of  September 2020.

Origins of SCA

The combination of these three paragraphs presents a real conundurum for banks. To understand why, it helps to track the origin of the RTS back to the original legislation, the PSD-2 where Article 97 requires Payment Service Providers to apply Strong Consumer Authentication. Paragraph 5 broadly states that the card issuer should allow the ecommerce merchant to use the issuer's own mode of authenticating the cardholder (emphasis mine).

5. Member States shall ensure that the account servicing payment service provider allows the payment initiation service provider and the account information service provider to rely on the authentication procedures provided by the account servicing payment service provider to the payment service user in accordance with paragraphs 1 and 3 and, where the payment initiation service provider is involved, in accordance with paragraphs 1, 2 and 3.

A History Lesson

The very raison d'être for 3-D Secure was for just this purpose. In the early 2000s, when eCommerce was still in its infancy, the Verified by Visa programme was launched to establish trust between the cardholder, the merchant and the card issuer. It also enabled any ecommerce merchant globally to check whether their consumer was a customer of a bank that provided 3-D Secure authentication, and if it was, then the transaction could be routed to the issuer so that the cardholder would receive a familiar authentication experience for every transaction.

As ecommerce matured and more transactions flowed through the ecosystem, card issuers could build a picture of what normal behaviour looked like for customer A and how that is likely rather differ from the behaviour of customer B. In essence, card issuers were able to very accurately discern the identity of the person initiating the transaction and precisely discrimate between fraudsters and consumers. Very similar methods are employed when banks receive payment requests that are out of the ordinary, e.g. having cards declined at ATMs overseas or when making an unusually expensive purchase. The EBA's decision to outlaw such a tried & tested approach will make it much harder for issuers to delivery an SCA compliant authentication procedure that is not doesn't sacrifice the cardholder experience.

Managing the Customer Experience

Almost every bank will need to develop  multiple authentication journeys as different sectors of their customer base will have different expectations, e.g. consumers will have different expectations from corporate cardholders, student account holders will differ from high-net worth customers etc. However, to avoid digital exclusion, every sector needs a SCA-compliant option and, unless the consumer has access to a smartphone with their bank's mobile banking application installed, ecommerce is likely to get a lot less fun.

In-App Biometrics  

The bank's application should be compliant with the EBA's requirements for SCA as it will convey possession and, depending on the modernity of the handset,  either knowledge or inherence. This should be the default option for most issuers as it will add the least amount of friction to the shopping experience for smartphone users.

A Fallback Solution

For those cardholders without a smartphone then it becomes a lot harder to apply SCA. Prior to the publication of the EBA's June 2019 Opinion paper, many Issuers were considering SMS-OTP + behavioural biometric (based on 3DS transaction data) as being compliant with the SCA requirements. Unfortunately, Paragraph 21 has outlawed that approach and, while an OTP delivered by SMS or to a landline can be used as a possessive factor, there are no good options for the second factor.

In this scenario, as the cardholder does not possess a smartphone, then very few of the EBA's preferred biometrics will be available, for example, facial recognition, fingerprint analysis, heart rate etc are all off the table. Keystroke dynamics may be an option but, when assessing solutions on the market, it appears as if the cardholder would have to type a 25-30 character phrase for an identity to be discerned to a suitable level of accuracy.

Ignoring the customer experience of this for a moment, while this approach would be possible in a browser-based transaction, it would not scale well to the other device types that EMV 3DS now supports. Imagine trying to do this when purchasing an eBook on a Kindle or a digital download on a Playstation. Even though, for this scenario, it is assumed that the cardholder doesn't possess a smartphone, this approach is also very unlikely to be supported if the transaction is being initiated from a mobile application.

Additionally, many of these behavioural profiling technologies seem to flow in the opposite direction to initiatives being launched by the mobile platforms to improve the privacy of their consumers and restrict access to technologies that could be used for malicious purposes. For example, Apple explicitly acknowledge that fraud detection capabilities may be compromised by their efforts to improve privacy but, in their view, consumer privacy is the higher priority.

In practical terms, this leaves many issuers with the only option of supplementing an SMS-OTP with a knowledge factor for SCA-compliance. Ideally, this shared secret should be used elsewhere, i.e. when accessing online or telephone banking etc., to reduce the need for the consumer to remember another credential. Issuers also need to consider how to collect this shared secret from consumers and allow consumers to reset it from time to time. Both of these activities also need to be protected by SCA.

This also presents a fairly poor customer experience as EMV 3DS (version 2.2) can only accept a single response per screen and so a two-stage challenge process would be required where the cardholder would first be prompted for an OTP and then a second screen would appear to prompt for the knowledge factor. Thanks to Article 4(3)a of the RTS, if either factor is incorrect, the consumer would have to start from scratch as they cannot be told which factor was entered incorrectly. While I understand the need for this from a security standpoint, it's going to cause a lot of frustration to real-world consumers.

Recommendations

The best option for most consumers will be to use a smartphone application to perform an in-app biometric authentication. If the application has been well-designed to take advantage of the mobile platform's accessibilty features then this should also scale well to those consumers with protected characteristics.

However, to avoid digital exclusion of the vulnerable, there are no good options and, frankly, the least worst option may be to turn the clock back a decade and deploy CAP readers to those customers. This would allow those consumers to perform compliant SCA through an OTP delivered by voice to a landline, or via SMS to a feature phone, to be combined with an OTP generated from the CAP reader once a card has been inserted and the correct PIN entered.

Conclusion

While it is often unfashionable to feel sympathy for banks, many are in an unenviable position where there are few good options to avoid the digital exclusion of some of their customer base. Additionally, the PSD-2 and the RTS can't be read in isolation as the banks are equally bound by legislation to avoid discrimating against those with disabilities. I can't profess to state legally which legislation carries more weight but, morally, it feels like compliance of the PSD-2 is a lower priority than that of certain disability legislation.

In my day job, I shall continue to work with the european and national regulators and the industry forums to try to identify a pragmatic middle ground to this conundrum but, at present, there are no good solutions. Please get in touch if you would like to learn more.