Newcomers | Designing a Future-Proof Combination of SCA Elements under PSD2 and PSR

Article Structure

1. The Basic Principles and Its Implementations
   1. From Different categories
   2. Independence between Each Other
   3. Reuse of Elements
2. The Evolvement from PSR
   1. Comprehensive Scenario Coverage
   2. Accessibility for Everyone
   3. Elements from Same Category
   4. Awaiting New RTS
3. A Future-Proofed Solution
   1. More Than Two Elements from More Than One Category for Each Scenario
   2. Reuse as Much as Possible
   3. Give Autonomy Back to Users

Bearing in mind those 3 different types of elements individually for SCA (Strong Customer Authentication), the task for the compliance and product teams is to combine elements to comply with the regulatory requirements for security enhance and fraud reduction, under both the current PSD2 (the Revised Payment Services Directive) and the foreseeing PSR (the Payment Services Regulation). Here, we are going to elaborate and experiment on designing a future-proofed compliant SCA solution.

1. The Basic Principles and Its Implementations

a. From Different Categories

This is direct, just take two elements, each from a different category (possession, knowledge, inherence). For example, for log-in, a PSP (payment services provider) may choose facial recognition (inherence) and password (knowledge) to combine. Similarly, for digital signature, as advised by EBA (European Banking Authority), if PSP needs to use a key stored in the user’s device which can only be accessed by entering the correct PIN or other forms of knowledge, then this digital signature also meets the requirement on different categories.

Notwithstanding, our imagination shall not be caged. It says from different categories but never says only 2 elements from different categories. We may have 3 or 4 elements from two or three categories as well (it’s not nonsense!).

b. Independence between Each Other

The elements used for SCA should be independent from each other. Independence applies both logically and technically. Article 9 of the PSD2 SCA RTS requires that the use of the elements ‘is subject to measures which ensure that, in terms of technology, algorithms and parameters, the breach of one of the elements does not compromise the reliability of the other elements’.

Logical independence could be easily understood. For example, if a person’s log-in password is stolen, but the log-in also requires facial recognition, then without the presence of this person, the log-in cannot happen.

Technical independence may need the support from IT team. It may require the adoption of trusted execution environments, the deployment of separate TOTP (Time-based One-Time Password) app protected cryptographically, multiple communication channels etc.

c. Reuse of Elements

In the same session of the authentication during log-in, for payment initiation, it’s considered acceptable to adopt only another one element to verify. It should be noted that this reuse of element still needs to follow “independence” and “different categories”. And for the new element which is to be carried out during the payment initiation, it shall enable the fulfilment of dynamic linking (dynamic linking and authentication code will be introduced in another piece). The reuse can provide the PSUs (Payment Service Users) with better user experience and simplify the design of SCA mechanism.

2. The Evolvement from PSR

As the upgrade in payment service regulation is coming, the SCA updates from PSD2 are spread out from Articles 85 to Article 89 in PSR. Here we touch on 4 observations.

a. Comprehensive Scenario Coverage

In PSR, besides 3 well-defined scenarios for SCA implementation, a risk-based approach is also taken to broaden the coverage. It requires PSPs to screen the customer journey, combined with industry knowledge and enterprise know-hows, to delineate potential fraud risk points and determine the necessity of SCA.

A payment service provider shall apply strong customer authentication where the payer:

(a)accesses its payment account online;

(b)accesses payment account information;

(c)places a payment order for an electronic payment transaction;

(d)carries out any action through a remote channel which may imply a risk of payment fraud or other abuses.

b. Accessibility for Everyone

From the point of view of product design, the effective Directive (EU) 2019/882 has been pushing consumer banking services to include accessibility requirements. The accessibility requirement is being advanced specifically to SCA application under the Article 88 of PSR with wider financial services scope.

To improve accessibility, the PSR requires PSPs to offer diverse authentication methods to allow everyone including people with conditions to use the offered financial services with equal chance under protection from fraud with compliant SCA. This includes persons with disabilities, older individuals, users with low digital literacy, and those without access to digital tools. It requires diversified solutions to be inclusive for different people compared to only single choice to authenticate. For example, for a desktop browser user, PSP shall not assume the user can authenticate with smart phone.

At this moment, the potential available options include but not limited to voice recognition, card-reader authentication, hardware tokens, desktop sync options, or assisted setup flows, etc.

Under PSD2, for compliance purpose, PSPs may choose to refuse to proceed for PSUs who fail to execute the designed SCA properly. In the future, under the proposed PSR, the accessibility is not only making the fraud protection from SCA accessible, but also the financial service per se.

c. Elements from Same Category

Contrary to the PSD2, PSR stipulates clearly that the elements for SCA do not necessarily belong to different categories. PSR preserves the requirement on full independence between each element. They realize that to preserve independence, from different categories is not a necessary condition. This reflects a regulatory shift, placing more responsibility on the market to ensure effective security and let the market player create above bottom line.

For those big players with better product and IT, they may explore same category solutions. For small players, to secure the independence level, they may remain using elements from different categories to achieve the regulatory requirement and keep the fraud countermeasure effective.

For accessibility, allowing SCA elements from same categories is necessary as well because certain elements are not highly accessible for all the people.

d. Awaiting New RTS

We shall foresee the coming of RTS to give detailed guidance after the PSR comes into effect. According to Article 89 of PSR, it’s believed that the state of art and the expressed voices from PSPs and PSPs are factors to decide how far the RTS shall be stretched realistically.

When developing the draft regulatory technical standards referred to in paragraph 1, the EBA shall take into account:

(a)the need to ensure an appropriate level of security for payment service users and payment service providers, through the adoption of effective and risk-based requirements;

(b)the need to ensure the safety of payment service users’ funds and personal data;

(c)the need to secure and maintain fair competition among all payment service providers;

(d)the need to ensure technology and business-model neutrality;

(e)the need to allow for the development of user-friendly, accessible and innovative means of payment.

3. A Future-Proofed Solution

No matter at which stage of SCA development, to create or refine, a PSP stands, a future-proofed solution could consider the following 3 points.

a. More Than Two Elements from More Than One Category for Each Scenario

Ideally, a matrix of SCA capabilities is to be established. It may define each element with identifying its category, independence compatibility, support for dynamic linking, accessibility level, and resistance to fraud.

After creating this matrix, taking desktop and mobile into account, based on the risk points analysis on the customer journey, for each scenario requiring SCA, more than 2 elements from more than 1 category including at least 1 highly accessible element shall be offered. It helps to comply with the current legislation but also easily adapt to the foreseen changes.

b. Reuse as Much as Possible

Reuse of elements has been explained above. I believe it will serve as a steering pivot in the new SCA era. The ultimate compliant goal is to reduce fraud for users. However, in essence, financial services are products for users to use. An amazing product shall be a compliant product. But a merely compliant product can sink without a trace in the market. Considering more scenarios to be designated as SCA-necessary, except choosing what elements are available to offer, to reuse element as much as possible in sessions will increase the user experience and, furthermore, lower the design difficulty of accessibility options.

c. Give Autonomy Back to Users

For the set-up of SCA, PSPs may give the autonomy back to PSUs deciding how to combine elements for different scenarios. Since educating customers about fraud is also mentioned as an obligation of PSP in PSR, and there are the aforementioned accessibility requirements, by guiding PSUs to customize their own compliant SCA solutions, it can achieve PSP for multiple regulatory purposes and make it a feature of your product.

 

This article consolidates existing regulations and forward-looking trends to offer a strategic view of combining SCA elements. As we prepare for a new era under the PSR, flexibility, user empowerment, and risk-based thinking can be central to SCA success. Please don’t hesitate to reach out for any discussion over this and any related topics.

In writing this piece, I found the following references useful:

PSD2

PSD2 SCA RTS

PSR

EBA Opinion on SCA

Ideem: How PSD3 Could Reshape the Future of Digital Identity

OneSpan: Prepare for PSD3

VIXIO: PSD3 Pending