SCA - SDK Introduction

Document purpose

This document describes the implementation of the Solaris-developed Software Development Kit (SDK) integration for simple customer execution of Strong Customer Authentication (SCA). It defines the methods, parameters and responses for the SCA, their functions and the client development required to implement the SDK. This solution offers customers a variety of ways to undertake SCA and provides Solaris and its clients with a means to fulfil regulatory requirements via a simple integration into a mobile app. It is intended for those clients wishing to give their customers flexibility over how they verify themselves online.

What is Strong Customer Authentication?

SCA is a requirement of the European Payment Services Directive (PSD2) to reduce fraud, by asking customers for additional verification when 'online'. This typically means when a customer:

• Accesses Their Account Online
• Makes Online Payments/Transfers Or Uses Card Online
• Performs any other action which may create a risk of payment fraud

SCA can also be referred to as Two-Factor Authentication (2FA), or potentially Multi-Factor Authentication (MFA). It is a second level of authentication by a customer.

SCA authentication factors and actions

SCA requires at least two independent factors from the following list of three to be used to authorise certain actions:

• Knowledge - something a customer knows (password, mPIN)
• Possession - something a customer has (SMS OTP, device registration)
• Inherence - something a customer is (Fingerprint or Face ID)

For example, a customer accessing their account with a username and password is also sent a onetime passcode (OTP) by SMS to a mobile device in their possession. The two factors used are Knowledge and Possession. Two factors from the same type are non-compliant, for example password and a PIN number (knowledge + knowledge). There are also technical requirements of device registration that need to be met to satisfy possession from a regulatory perspective.

Why the SDK?

Solaris – as the regulated emoney account provider – has control over the application of SCA through the SDK, though the screens are customisable to match your colours/fonts/logo to improve the UI for your customers. This allows for the Solaris platform to dynamically link payments without the need to send an OTP which in turn improves the customer experience. Authenticating via app is seen as the gold standard for authentication, especially for those devices that have biometric capability. Solutions built around these fulfil one of the main requirements to deliver customer journeys as seamless and as friendly as possible. Even though SCA, by definition, brings additional friction into customer journeys. The SDK offers standard options for authentication that customers are already used to completing for other payment providers, such as device registration and finger/face authentication. The SDK also determines which are the most appropriate and simplest methods based on the customer's use of their device.

Currently the industry has been given an extension for online card shopping, because the Schemes approach was deemed to be uncompliant, however, utilising the SDK means a fully compliant SCA solution for online card shopping, which would be ahead of many industry players.

SCA authentication factor rules

There are a complex set of regulatory rules and technical requirements governing factor carry-over and exemptions that can be utilised to remove the requirement for SCA in every event. The SDK and associated APIs manage these rules, whilst maintaining compliance. For example, the regulations allow a first-factor 1FA to be carried over from Login to be used as a factor for further SCA events whilst the customer remains in session. Clients will advise Solaris of the factors used at customer Login via the API method or the SDK itself can be used for a 2nd FA for Login. A customer will always have an option to manually choose another action in the SDK screens, for example, if their phone camera has recently broken and they cannot perform facial recognition, despite the device being capable. Within the SDK, preference is always given to 'Tap on the App' and biometrics for customer simplicity, when the conditions can be met. See SDK use cases for examples using the Canvas App.

For more information about which customer actions require SCA, see the SCA events and exemptions table.

Client implementation - review and approval by Solaris

Solaris as a regulated entity responsible for SCA is required to approve client's implementation of the SDK. We will discuss the detailed requirements of this review with you as part of your implementation.