Portal – Introduction

Document purpose

This document describes the implementation of the Contis API solution for Strong Customer Authentication (SCA). This offers a single authentication solution – One Time Passcodes (OTP) to fulfil regulatory requirements.

Who is it for?

This solution is most suited to portal-only customer accounts where authentication ‘via app’ is not possible.

If you provide your customers with an app please see the Contis SDK implementation guide as this offers multi-authentication capability including biometrics, via a simple integration. It also reduces the cost associated with OTPs via SMS and mitigates network issues experienced by the customer.

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).

If possession via device registration is being used, there are technical requirements that need to be met to satisfy possession from a regulatory perspective.

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 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 Contis of the factors used at customer Login via an API method.

See the Portal-only use cases for Login and Make a payment for example customer journeys using the OTP solution.

Important! The application of SCA is mandatory. Either the portal only solution using APIs and OTPs passcodes or the app solution using the SDK and Multi authentication capability must be implemented.

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

Important! Online card transactions already use the OTP solution so this will not be subject to any change. This is currently only a 1FA journey (there is no SCA login to a customer account). Regulation requires this journey to become 2FA compliant by December 2020 therefore future development to this journey will be required in order to achieve full compliance (the SDK solution does achieve 2FA compliance for this journey)

The role of Contis

Contis is the regulated emoney account provider and therefore is accountable for all SCA-related activities. Contis is required under the regulations to dynamically link payments. Clients will create the user interface for the OTP entry, but the OTP generation must be performed by Contis.

Contis is required to approve Client’s implementation of the API OTP solution. We will discuss the detailed requirements of this review with you as part of your implementation.