Reference Architecture on Implementing TRA and SCA Exemptions

Executive Summary

• Regulatory Technical Standards (RTS) for PSD2 mandates the use of Strong Customer Authentication (SCA) to ensure security in remote payments as frauds have been identified as the main threat.
• SCA Exemptions and Transaction Risk Analysis (TRA) defined in RTS ensures that strong customer authentication is applied without impacting user experience.
• WSO2 Open Banking has inbuilt capability to support SCA exemptions via the TRA module which is easily pluggable, configurable, and extensible. Capabilities built into WSO2 Identity Server, such as authentication framework and adaptive authentication, simplify the process of implementing real time TRA and fraud detection securely.

Introduction

Fraud in remote payments is one of the main threats faced by banks and payment service providers today. Hence, according to the RTS for PSD2 in the European open banking regime, banks and payment service providers are required to use SCA to ensure security in remote payments. TRA is the method defined in the RTS for identifying possible frauds and risks by counterparties and, in the interests of user experience, for exempting SCA for transactions deemed likely to be non-fraudulent. This article discusses the reference architecture used in WSO2 Open Banking for TRA and SCA exemption implementation.

Regulatory Technical Standards

RTS was published by the European Banking Authority (EBA) in accordance with Article 98 of the Revised Payment Services Directive (PSD2). It specifies requirements and exemptions for Strong Customer Authentication and also provides guidance for authentication, authorization, and other security aspects important in implementing PSD2.

TRA and SCA Exemptions falls under the Strong Customer Authentication and Fraud Detection requirements in the RTS.

Strong Customer Authentication

SCA is a requirement of PSD2 which ensures the security of the transactions performed. It ensures that the users are authenticated using multifactor authentication (MFA) in order to make online transactions and online actions more secure. Elements used as authentication factors should be able to be categorized into one of the following:

• Knowledge - Something only the user knows
• Possession - Something only the user possesses
• Inherence - Something the user is

MFA is a secure methodology used to verify the identity of the user by adding more than one authentication steps. These authentication steps should be able to categorize as one of the above three categories and should provide a user’s identity information.

Transaction Risk Analysis

TRA is the method defined in RTS for identifying possible frauds and risks by counterparties and exempting SCA for non-fraudulent transactions under PSD2. TRA is a common method used in fraud detection and risk analysis where real time processing is key. Understanding and using TRA will enable banks and payment service providers to support transaction risk monitoring specified in PSD2.

SCA Exemptions Defined in RTS

SCA exemptions defined in the RTS are scenarios where the bank or the payment service provider can exempt users from using multi-factor authentication. Rather, in these scenarios, users can directly proceed with transactions after basic authentication.

These exemptions are introduced to enhance usability user experience while maintaining the security of transactions. Listed below are the use cases defined for SCA exemptions in the RTS:

• Access to the balance and recent transactions of a payment account without disclosure of sensitive payment data
• Recurring payments to the same payees which have been previously set up or confirmed by the payer through the use of SCA
• The payer initiates a credit transfer where the payer and payee are the same natural or legal person and both payment accounts are held by the same bank
• Low-value contactless payments at points of sale
• Online purchases of low value
• Electronic payment transactions initiated at unattended terminals
• Corporate payments which have been initiated through dedicated processes or protocols that guarantee the high levels of payment security payment service providers

For more details, refer to this article on TRA for open banking and PSD2.

Authentication Flow With TRA Enabled

For TRA and SCA exemptions to be executed, multi-factor authentication should be configured in your WSO2 Open Banking deployment. Usually, the Basic Authentication is based on the username-password concept and any other authenticators like SMS OTP and TOTP can be used as other factors. Based on the bank's requirement these authenticators can be changed and customized in WSO2 Open Banking.

The figure below shows the authentication flow when the TRA module is activated in WSO2 Open Banking.

First, the user will be redirected to Basic Authentication and after successful authentication from Basic Authentication, the TRA Module will be executed from the flow to take a decision on whether to apply SCA or not. Execution of this module will be triggered from the script which enables the adaptive authentication capability lies in WSO2 Identity Server. Adaptive authentication is a secure and flexible way of handling multi-factor authentication. It enables the authentication to be handled in different ways (i.e. either via basic authentication or multi-factor authentication) based on different attributes in the context. These attributes used to determine the authentication can be based on considerations such as risk factor, device, and location.

WSO2 Open Banking supports Script Based Adaptive Authentication where a script is used to set different attributes to the context depending on the scenario. This script will handle the application of authentication factors by executing external modules and apply the authenticators to the transaction instead of enforcing all authenticators to every transaction.

Reference Architecture Used for TRA and SCA Exemptions in WSO2 Open Banking

WSO2 Open Banking has implemented the TRA and SCA exemptions in a configurable and extensible way. Hence, the customer banks get the capability to add more rules in addition to those implemented by default in the WSO2 Open Banking system.

The figure above shows the full architecture used in WSO2 Open Banking to support TRA and SCA exemptions.

TRA Module in WSO2 Open Banking

The TRA Module is the decision-making unit for TRA. It has been developed based on the WSO2 Stream Processor (now known as WSO2 Streaming Integrator) and the Siddhi Query Language. This module consists of a set of validators developed based on the SCA exemptions and TRA Rules set out in the RTS. These validators evaluate transactions and produce outputs on whether SCA may be exempted or not. This output will be directed to the authentication flow and based on the factors in the adaptive authentication script, the second factor will be exempted or applied as recommended for the transaction.

As mentioned before, the TRA module is developed based on the WSO2 Stream Processor and the Siddhi Query Language as it needs to process large amounts of data in real time to get the correct output. Since a large amount of data is processed during the authentication flow, this could slow down the flow and impact the user experience. To avoid that WSO2 Stream Processor is used as it is designed to be an SQL-based, high performant, lightweight, open source stream processing platform that facilitates real-time data processing.

The TRA module consists of different sets of validation units for each of the request types (accounts and payments). The WSO2 Open Banking Identity Access Management module will determine the request type of each transaction and the relevant validation unit will be called in the WSO2 Open Banking Business Intelligence module. This means, there will be only one call from the identity and access management (IAM) module to the Business Intelligence module to avoid performance leakages. Also, when the relevant validation unit is called, all the validators will be executed and only the final result will be sent to the IAM module.

These validation units are developed in such a manner that the customers can easily plug and deploy any new validator. The deployed validators will take the input from relevant Validation Initializers and will send the output to the same in-memory table. Finally, the Result Analyser will evaluate the results from the validators and give the final output. So the customer has to develop a validator using the Siddhi Query Language having the same input and output as the other validator and deploy the validator in WSO2 Business Intelligence.

Conclusion

What may be seen is that PSD2 has emphasized on Second Factor Authentication to ensure that the transactions initiated via banks and payment service providers are secure and better positioned to prevent fraud. SCA exemptions introduced in the RTS have been implemented in the TRA and fraud detection to ensure that strong customer authentication is applied without impacting user experience.

Capabilities built into WSO2 Identity Server, such as authentication framework and adaptive authentication, simplify the process of implementing real time TRA and fraud detection securely. Large amounts of data are processed in a few milliseconds using WSO2 Stream Processor to facilitate real-time data processing. Easily pluggable, configurable, and extendible WSO2 Open Banking has these capabilities out of the box. Please refer to these documents on TRA for the UK and working with fraud detection for more details on how TRA and SCA exemptions may be rapidly implemented with your open banking deployment. To learn more about WSO2 Open Banking, click here.