Transaction Risk Analysis

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

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 he 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 ASPS 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.

Configuring Transaction Risk Analysis 

Open open-banking.xml in  <KM_HOME>/repository/conf/finance and <AM_HOME>/repository/conf/finance to update enable transaction risk analysis as below.

<TRA>
<IsEnabled>true</IsEnabled>
</TRA>

Next, create a transaction risk analysis validator and pack as a jar file in <KM_HOME>/repository/component/dropins by following the steps given below.

1. Create a new Java class that extends com.wso2.finance.open.banking.transaction.risk.analysis.validator.functions.uk.ValidateFunction and provide an implementation to the validate function according to the requirements.
2. Add a new <Validator> tag inside <TRA><Validators><Account> for accounts API Validators or <TRA><Validators><Payment> for payment API validators.
3. Add the full package name + class name for the validator class inside the <Validator> tag as below and restart the server.   
   Example:<Validator>com.wso2.finance.open.banking.transaction.risk.analysis.classname</Validator>