Solving for SCA with Consumer Device Cardholder Verification Method (CDCVM)

Solving for SCA with Consumer Device Cardholder Verification Method (CDCVM)

Martin Koderisch
May 1, 2019

I’ve just checked the countdown widget on our SCA page and its 135 days and 12 hours to go until the SCA effective day of Sept 14th! Preparations in the payment card ecosystem are now in full swing. VISA and Mastercard recently published their official guidelines for achieving SCA compliance via EMV 3D Secure. Further updates are in the pipeline. Including a program that will allow issuers to delegate SCA to third parties, and in particular, rely on smartphone devices with Consumer Device Cardholder Verification Method (CDCVM) to authenticate their cardholders. In this scenario, the smartphone becomes an authentication device. Issuers will still need to support 3D Secure for the myriad of use cases where the CDCVM cannot be used. But as this article will attempt to explain, smartphone-enabled payments using the CDCVM may prove to be a popular choice for consumers seeking a quick check out experience both on mobile and desktop.

3D Secure version 2

The 3DS version 2 protocol is supposedly a radical improvement on version 1. It supports an improved user experience and includes so-called frictionless flow based on the outcome of real-time risk analysis. This system relies on merchants sharing more data with issuers via the 3DS architecture to allow issuers to assess risk and make decisions in real time. So post SCA payment flow will be along the lines of a merchant sending authentication request from their 3DS server to an issuers ACS via the schemes DS. The issuer will put additional capabilities in place to make a real-time risk assessment based on the transaction data shared by the merchant. If the issuer determines the transaction as low risk, he may apply the TRA exemption, or acknowledge an exemption applied by the acquirer, and will return an authentication code to the merchant that is then inserted into the subsequent authorisation message back to the issuer. Payment authorisation is then processed as normal. On the other hand, if the issuer does not view the transaction as sufficiently low risk, he will decide to step up and present an SCA compliant challenge to the cardholder.

The problem with 3DS2 is that firstly it pushes a lot of complexity into the back end in order to simplify the user experience at the front, and secondly the entire value chain needs to migrate in tandem for the system to work. It will happen but not quickly enough to meet the September 14 deadline. There are in fact two subversions of 3DS2 spec. The first version, 3DS2.1 was published by EMVCo in Aug 2018, just one year before the SCA effective date deadline. In payment terms, that is a very short period of time for full implementation. Many issuers and acquirers are behind schedule and as a result, so are the merchants. Not only that but to achieve the full benefits of the 3DS2 frictionless flow vision actually requires a later version of the spec called 3DS2.2. There is growing acknowledgment that payment ecosystem will not migrate to v2.2 until mid-2020 at the earliest. It is possible that, come the 14 September,  support for 3DS version 2 will be patchy at best. In fact, schemes are suggesting that merchants need to support and fall back on the old original 3DS version 1. Moreover, many issuers are simply risk-averse and will be very cautious about scoring transactions as low risk and not stepping up. In many EU markets, it may take time for issuers to fully support the frictionless flow based on low-risk assessment. In the meantime, the step up frequency will be high and it looks likely that a frictionless flow will be the exception rather than the norm.

Consumer Device Cardholder Verification Method (CDCVM)

Another SCA compliant solution is the so-called Consumer Device Cardholder Verification Method (CDCVM) and is supported by the card schemes. It has perhaps been so far slightly overlooked as the focus has been on getting 3DSv2 up and running. It will most probably receive more attention soon, as further SCA guidance and updates from the schemes are expected. To quote Mastercard's latest SCA guidelines, 'including a program that will allow issuers to delegate SCA to third parties, and in particular, rely on smartphone devices with Consumer Device Cardholder Verification Method (CDCVM) to authenticate their cardholders'. In this scenario, the smartphone becomes the authentication device. So rather than sending 3DS messages and challenges back and forth, SCA compliant authentication is completed on the device itself.

So for example, on Apple Pay, Face ID, Touch ID, or even the device passcode can be used as the consumer device verification method. Same applies for Google Pay on Android smartphones.

Importantly the CDCVM works for in-app and remote payments as well as contactless payments at the POS. ApplePay can now also be accessed and used on any laptop or desktop with a Safari browser. Checking out with ApplePay in a Safari browser will trigger the Apple Pay wallet pop up screen simultaneously on both the browser and the linked iPhone and prompt the user to authenticate and confirm the payment via  TouchID / FaceID on the iPhone.....

......or, on the latest generation of MacBook Airs and MacBook Pros by Touch ID on the laptop itself. In this scenario, the laptop is the authentication device and no other smartphone device is required. If it proves successful, other laptop brands will no doubt follow suit ...

Hence, CDCVM becomes a very viable solution for fast SCA compliance. This kind of channel cross over or decoupled scenario is part of the 3D Secure vision too but isn't yet available.

CDCVM is SCA compliant because the card has first been digitally provisioned, verified and tokenised into the mobile wallet of a device. The token associated with the device then qualifies as the first factor (something you possess). The second factor is the biometric fingerprint or face scan (something you are) typically used by Apple and Google Pay. The CDCVM process is already up and running with all necessary players of the payment system on board. Merchants thus do not need to wait and can proactively decide to support Apple and Google Pay as a payment option on their check out page.

Indeed the expectation is that use of CDCVM will expand to include more devices such as wearables and other IoT devices, and compliant authentication technologies such as behavioural biometrics. All the major schemes support CDCVM and are coordinating via EMVCo and the Fido Alliance to set further network security standards and technical requirements for devices to be securely used for authentication and thus create the conditions for the expanded use of CDCVM going forward. EMVCo released the initial version of guidelines in March:

Consumer behaviour after SCA

Users will, I suspect, learn very quickly. They will figure out which payment method or check out option supports the most friction-free check out flow. They will as a consequence start to place even more weight on payment experience when deciding at the merchant to shop at. Smart merchants will offer an option that uses CDCVM and smart users will use it. This could gain traction across e-commerce and in the end, play to the advantage of Apple Pay, Google Pay, and other devices that qualify for CDCVM.

The content of this article does not reflect the official opinion of Edgar, Dunn & Company. The information and views expressed in this publication belong solely to the author(s).

Engage with EDC

Lets discuss how EDC can assist your business

Connect with us

Become part of
the EDC team

Want to join the EDC team?

Find out more
Back to top