This site contains the documentation that is relevant to older WSO2 product versions and offerings.
For the latest WSO2 documentation, visit https://wso2.com/documentation/.

Transaction Risk Analysis

Owned by Former user (Deleted)
Last updated: Jun 30, 2020
2 min read

Bank's customers/PSU can use third-party applications that are made available by AISPs and PISPs to view account information and do online payments. Initially, these third-party applications collect the PSU's consent to initiate an API call to the Bank's/ASPSP's backend system, which will return a consent ID,  which is either an AccountRequestId (AISP flow) or a PaymentsId (PISP flow). Next, the PSU has to get through the ASPSP's authorization flow in order to view the account information or to perform the online payment, during which the consent ID will be passed to the ASPSP's backend system as a request object claim value. During the authorization flow, the PSU has to be authenticated against the PSU's credentials and the apply second factor for SCA. However, WSO2 Open Banking is capable of analyzing the risk level based on predefined rules and exempt the user from having to provide the second factor. 

This functionality is in line with the Chapter III Exemptions from Strong Customer Authentication, which is a Commission Delegated Regulation (EU) supplementing Directive 2015/2366 of the European Parliament and of the Council with regard to Regulatory Technical Standards (RTS) for strong customer authentication and common and secure open standards of communication.

Let's take a look at the scenarios that are used to eliminate the second factor from the authentication process.

Exempting the second factor based on the PSU's transaction history

The ASPS can determine the time period during which the PSU can view the account balance that the PSU had accessed previously at least once, without having to provide the second factor at the user authentication, e.g., accessing transaction history of a payment that the PSU accessed within 90 days.

Exempting the second factor based on the PSU's transaction amount

The ASPS can exempt the PSU from entering the second factor for online payments if the transaction amount is within the predefined limits.

Examples:

  1. Exempting the transactions that are less than £30.
  2. Exempting the transactions where the accumulated transaction amount is less than £100 where the PSU had already provided the second factor for the previous transaction.
  3. Exempting the next five transactions after the PSU provides the second factor. 

Exempting the second factor where payer and payee are the same

The ASPSP can exempt the PSUs who transferring money between own accounts, e.g., the PSU transferring money between the accounts in the same bank.

Exempting the second factor based on the PSU's account beneficiary list

The ASPSP can exempt the second-factor authentication for the payments to the payees that are maintained in the PSU's beneficiary list.

Exempting the second factor for recurrent payments

The ASPSP can exempt the second-factor authentication for certain recurrent payments, e.g., recurrent payments of the same amount to the same beneficiary.

Exempting the second factor for low-risk transactions

The ASPSP can exempt the second-factor authentication for low-risk transactions. This gets triggered if none of the above factors are met. 

Apart from Transaction Risk Analysis, WSO2 Open Banking add an extra level of security by identifying fraudulent transactions and applying SCA when required. For more information on the Fraud Detection module in WSO2 Open Banking, see Working with Fraud Detection.