Difference between revisions of "Strong Customer Authentication"

From MgmtWiki
Jump to: navigation, search
(Reference)
(Context)
Line 25: Line 25:
 
* Something the customer knows like a password or PIN
 
* Something the customer knows like a password or PIN
 
* Something the customer has like their phone or a hardware token
 
* Something the customer has like their phone or a hardware token
* Something they are like fingerprint or facial biometric recognition
+
* Something they are like the biometrics of fingerprint or {{Facial Recognition]]
 
Many new MFA designs are opting for the “something the customer has” (smart phone)
 
Many new MFA designs are opting for the “something the customer has” (smart phone)
 
accompanied with a biometric read, “something the customer is”. This MFA process is
 
accompanied with a biometric read, “something the customer is”. This MFA process is

Revision as of 13:29, 27 May 2021

Full Title

Strong Customer Authentication (SCA) – Addressing the Consumer Experience and the Complexity of the Workflow

Context

Payment Services Directive v2 (PSD2) has introduced the concept of Strong Customer Authentication (SCA) to financial transaction workflows occurring within or involving the EU. The intention of this security requirement is to reduce fraud and make online financial transactions more secure. To achieve this goal, the requirements published in the Regulatory Technical Standards (RTS) for SCA aim to ensure that the customer who is attempting to initiate an electronic payment transaction or access their account online is who they say they are. This new requirement raises questions around the implications surrounding the consumer experience and the technical complexity to solve this challenge. - Consumer Experience – Are consumers willing to endure a bit of authentication friction to deter fraud? Will a more robust authentication process harm the retailer’s brand? - Complexity – Multifactor authentication and dynamic linking requirements must be done with speed and efficiency Consumer Experience: SCA will require that the customer be able to apply at least 2 of 3 authentication factors – a concept known as Multifactor Authentication or MFA – during the course of the transaction. This process is expected to greatly reduce the number of fraudulent transactions that occur every day while introducing a new work flow that is easy for the customer to perform. Instead of the traditional username and password design, which was easy for fraudsters to exploit, consumers will be called upon to provide at least 2 of 3 authentication factors listed below:

  • Something the customer knows like a password or PIN
  • Something the customer has like their phone or a hardware token
  • Something they are like the biometrics of fingerprint or {{Facial Recognition]]

Many new MFA designs are opting for the “something the customer has” (smart phone) accompanied with a biometric read, “something the customer is”. This MFA process is especially convenient because it one that can be accommodated directly on the consumer’s own smart phone and doesn’t require the consumer to purchase a new piece of technology or carry something with them that only has a single purpose. Consumers are also familiar with the biometric read process. It is used regularly by consumers to unlock their device and is often used as a shortcut to bypass entering their PIN when logging in to a secure site.

If designed properly, an MFA experience needn’t harm the entity’s brand by making the transaction appear more onerous. As a completely integrated element of the transaction workflow, the use of a biometric read on device will appear as fast and secure as any other instance where the consumer applies their fingerprint or facial image read. Complexity: Adding a highly secure, multifactor workflow to transactions will provide assurances that the parties involved in the transaction are who they say they are. Another security element that is key to solving this challenge of identity confidence is a concept known as “dynamic linking”. Dynamic linking requires that a unique authentication code be applied specific to the transaction amount and the recipient and that the transaction amount and recipient are made clear to the payer when authenticating. The dynamic linking requirement states:

  • the payer is made aware of the amount of the payment transaction and of the payee;
  • the authentication code generated is specific to the amount of the payment transaction and the payee agreed to by the payer when initiating the transaction;
  • the authentication code accepted by the payment service provider corresponds to the original specific amount of the payment transaction and to the identity of the payee agreed to by the payer;
  • any change to the amount or the payee results in the invalidation of the authentication code generated. “

While consumers will not be aware of technical details underpinning dynamic linking, they will appreciate that the name of the Payee and the Amount of the transaction are clearly displayed before they agree to the transaction. Behind the scenes, payment service providers will be exchanging these transaction details between the parties using strong encryption measures ensuring confidentiality, authenticity and integrity.

Is this relevant to a healthcare use case other than a financial txn?

As a result of MFA and dynamic linking, all parties involved in the transaction will benefit from a more secure financial transaction workflow. It is also anticipated that the speed and convenience of this design will boost eCommerce trade and may also have implications for other industry sectors.

Reference