Strong Customer Authentication

Strong Customer Authentication at a glance

Strong Customer Authentication (SCA) is a requirement of the European Payment Services Directive (PSD2) to add additional layers of security to electronic payments, primarily in order to reduce fraud. SCA is applicable both in the UK and the European Economic Area (EEA).

For reasons of compliance, Solaris must ensure that when undertaking certain journeys - referred to as "SCA events", customers (users) must authenticate themselves using Two-Factor Authentication (2FA), also known as Multi-Factor Authentication (MFA), within the prescribed time. Examples of these events include:

When a customer attempts to access their account.
When a customer makes a payment or transfer.
When a customer updates their contact information such as their address or mobile number.

This guide provides an overview of SCA including compliant factors for authentication, the journeys/events in scope and exemptions where SCA may not apply.

SCA Events

Certain workflows (events) undertaken by a user will require them to authenticate themselves, with SCA typically applying to the following event types:

Customer login.
Change of customer contact information - phone number, address, email address etc.
Payments.
e-Commerce transactions.
Creation of / amendment to / removal of a trusted beneficiary.
The setting up of a standing order.
5 minute customer inactivity timeout.

Please note the user sign up process is not considered an SCA event.

SCA Exemptions

Exemptions

The use of exemptions by Solaris is discretionary and certain exemptions are only permissible where fraud levels remain under prescribed limits. The use and application of exemptions is subject to change by Solaris.

For certain SCA events exemptions are available, meaning the customer will not need to perform 2FA in particular scenarios. The table below details an overview of SCA events and example exemptions, if applicable:

SCA Event	Exemptions available?	Notes on exemptions
Customer Login	Yes *	Exemption available if the customer is only able to view the account balance and/or up to 90 day's worth of transactions. Exemption only applicable if the customer is not viewing the account details for the first time, and if 2FA has been performed by the customer in the last 90 days.
Change of customer contact information	No	SCA must be performed in all cases.
Card Spend - Contactless	Yes **	Exemptions limited by the cumulative amount of consecutive contactless transactions.
Card Spend - Online (includes stored card details)	Yes **	Exemptions determined by Transactional Risk Analysis.
Payments	Yes	Exemptions for Trusted Beneficiaries and low value payments.
Creation/changing a standing order	No	SCA must be performed in all cases.
Trusted beneficiary added/changed/removed for payments/transfers	No	One payment to be made, before functionality available to customer

* Please note, although exemptions are available for the customer login event, it is strongly recommended to perform SCA on all login events to provide a consistent and secure journey.

** Please note it is not always possible to predict in advance whether SCA will apply to a given transaction, or if an exemption will be available. The following conditions will apply:

The level of risk involved in the service provided.
The transaction amount, the recurrence of the transaction, or both.
The payment channel used for the execution of the transaction.

SCA Factors

Authentication Compliance

When authenticating, you must use two factors from separate categories.

SCA is usually achieved by applying Two-Factor Authentication (2FA) for the required event. When performing SCA, two independent factors from the three categories shown below must be used.

Knowledge - Something only the customer knows (e.g. password, mobile PIN).
Possession - Something only the customer has (e.g. a trusted device, One Time Passcode (OTP)).
Inherence - Something only the customer is (e.g. facial recognition, fingerprint).

Compliant Factors

To be compliant when authenticating, two factors from separate categories must be provided.

Examples of non compliant factor combinations:

Facial recognition along with a fingerprint - these are both factors of inherence.
Username and Password along with a mobile PIN - these are both factors of knowledge.

Examples of compliant factor combinations:

Trusted Device along with a fingerprint - combines factors of Possession and Inherence.
Username and Password along with a One Time Passcode (OTP) - combined factors of Knowledge and Possession.

Detailed below is a non-exhaustive list of compliant factors in each of the three categories:

Knowledge

Username and Password
mobile PIN

Please note Single Sign-On (SSO) will typically not be consisted a valid Knowledge factor for SCA, due to the validation being performed by a third-party, and not by Solaris or the partner.

Possession

One Time Passcode (OTP) *
Trusted Device/Device Binding
Third Party Authenticators

Please note

Solaris will review third-party authenticators on a cases-by-case basis.
If possession via trusted device registration/device binding is being used, there are technical requirements that must be met to satisfy possession from a regulatory perspective.
* If using OTP as a possession factor for 3-D secure journeys , the OTP must relate specifically to the transaction requiring authentication.

Inherence

Facial recognition
Fingerprint

Please note While the above are the two most common methods of proving inherence, Solaris will review any alternative methods as required.

Factor Carrying

If a customer is logged in and still in session, any further in-app SCA events that are initiated require only one additional factor to be performed, as it is permitted to carry one factor from the login event over to subsequent events.  