3D Secure

3D Secure (Three-Domain Secure or 3DS) is an additional authentication step which provides an added layer of security for online card transactions by reducing the risk of unauthorized card use due to the card not being physically present.

The three domains involved in the 3D Secure protocol are:

• Acquirer domain (merchant) - where transactions are initiated
• Issuer domain (Paymentology) - where transactions are authenticated and authorized
• Interoperability domain (network) - where transactions are switched between acquirer and issuer domains.

The 3DS process consists of three phases:

1. Card enrolment - enrolling a card with the 3DS ACS (Access Control Server)
2. Authentication - to authenticate the cardholder before moving on to the next phase of the process.
3. Authorization - considers the outcome of the authentication step before checking business-as-usual authorization criteria such as the availability of funds and approving the transaction.

Versioning and features

3DS has evolved from the initial version, and currently running on V2.1 and V2.2. Features include:

• More data sent during the message flow from the merchant and buyers’ devices to the issuer to evaluate the risk level of the transaction. The data points have increased tenfold from V1.
• Cardholder authentication is only required if the transaction is deemed suspicious.
• Only Dynamic OTP are allowed.
• Europe and UK: This is aligned to SCA (Strong Customer Authentication) a requirement of PSD2-RTS (2nd Payment Services Directive – Regulatory Technical Standards) which adds extra layers of security to electronic payments – applicable to the European Economic Area (EEA) and the UK.
• SCA Requires two-factor authentication, namely TWO of the following elements have to be systematically used during the authentication process:
  • Knowledge – Something only the cardholder knows (password, PIN, memorable info)
  • Possession – Something only the cardholder has (Mobile phone, card, key fob)
  • Inherence – Something the cardholder is (finger, face, voice, behavioural biometrics)

Configuration optionality

Paymentology offers a modern and flexible 3DS solution for clients. The ACS supports 3DS V2+, with full support for issuer SCA exemptions such as TRA (Transaction Risk Analysis) and merchant whitelisting.

Integration and implementation is handled by Paymentology's Implementation team during initial client implementation or if client chooses to utilise Paymentology's 3DS solution at any stage.

During 3DS ACS product scoping, clients are able to choose challenge method(s), risk profiles, challenge interface, risk engine, challenge interface locale and card program(s). Once clients have chosen their desired configuration and setup, Paymentology implements this.

Challenge methods

Currently supported authentication methods to choose from during initial implementation are:

• Out of Band (OOB)

  ---

  In this method mobile authentication can be done. Mobile authentication methods include mobile push notification, biometric verification and facial recognition. These are also classified as dual factor authentication which is widely used for Strong Customer Authentication (SCA) which is mandated in certain regions and countries by networks and/or governing data policies.

• SMS OTP

  ---

  In this method the cardholder is sent an OTP via the ACS system, Paymentology or client system based on where the cardholder details are shared and SMS gateway integration is done, once the cardholder receives the OTP they then enter it into the 3DS webpage popup by the Acquirer's ACS. Once OTP is verified the 3DS verification is performed.

• Alternative methods

  ---

  • Voice call OTP: in this method a one-time password is provided to the cardholder via voice call to their registered mobile number. Suitable for some cardholder demographics.
  • Email OTP: in this method a on-time password is emailed to the cardholders registered email address. Suitable as a back-up method in the event SMS OTP delivery has failed.
• Knowledge factor

  ---

  Cardholder are challenged to correctly identify historical transactions and memorable information such as password or PIN.

Challenge method and challenge profiles

• If challenge method and challenge profile are both populated, challenge profile takes precedent and will be used.
• Once a challenge profile ID is configured for the card, this is unable to revert to using challenge method.

🗒️

Challenge profiles afford the flexibility to alter the challenge methods of cards as a group as opposed to singularly. Instead of enrolling cards with a challenge method, cards will be enrolled with a challenge profile ID and the alias or uuid of the created challenge profile.

Challenge method failure

In the event a challenge method fails, clients can choose to have a secondary default configured, such as knowledge factor. Example, OOB fails, then knowledge factor authentication would kick in.

Risk profiles

Risk profiles define how the evaluation of a transaction is conducted once it reaches the ACS. A default risk profile is provided upon setup.

Conditional risk rules

Conditional risk rules add a layer of flexibility to your risk profile configuration as they determine whether to challenge, accept or proceed to the next risk rule. For example:

• Challenge if a merchant is from the following countries: New Zealand, Australia and Fiji. If not, proceed to next rule;
• Accept if MCC is 1731. If not, proceed to next rule;
• Accept if the amount is less than 50 EUR and the merchant country is Portugal. If not, proceed to next rule;
• Challenge if the merchant country is NZ or the amount in AUD is greater than 100. If not, proceed to next rule etc.

Challenge interface

A cardholder is presented with the challenge interface when challenged during a transaction. A default challenge interface can be configured, or clients can customise the interface with logos, branding etc.

Specific languages are able to be set for the challenge interface.

Risk engine

Clients can opt to use the ACS risk engine or make use of your own. This is configured through the portal or via API. Users can create multiple customised risk engines and manage them.

Card program

In the ACS a card program is a grouping of cards. These groupings are based on the logic you wish to group cards into. For example this could be by geography, demographic, card product or card group on the Banking.live platform.
The ACS card programs can have different experiences for its users, such as risk profiles and challenge interfaces.
As card program's are optional, in the event one is not created a default card program is set that encapsulates all cards.

Portal/User Interface

Clients are able to monitor key metrics, manage users and related permissions, adjust risk parameters and challenge configuration and track support tickets.

Paymentology will set up the initial client user. This user is then able to set up others within their organisation.

More reference guides