Default Rules in OneSpan Risk Analytics for Corporate Banking

OneSpan Risk Analytics for Corporate Banking is pre-configured with a number of default rules and factors for corporate banking applications to:

• Prevent different types of fraud attacks such as account takeover or phishing attacks.

• Handle session anomalies.

• Manage risks for several kinds of corporate banking events such as changing profiles, managing beneficiaries, and tracking fund transfers.

The corporate banking template also includes rules to comply with Regulatory Technical Standards (RTS) requirements under PSD2. These pre-defined default rules and factors apply to both non-monetary events and transactions.

The OneSpan Risk Analytics for Corporate Banking rules provided in Risk Analytics are based on information provided for each event, and on aggregation factors computed in real time. The factors also provide the necessary features for the machine learning component to score events and transactions. Machine learning models are part of the Decision Analytics Server which aggregates the event data and scores it in real- or near-time. The Decision Engine handles the rules that are processed inside the Oracle Database, executes them, and triggers the actions.

To view, configure, and extend the default corporate banking rules of Risk Analytics to your application flows, navigate to the Design Rules & Actions page in OneSpan Risk Analytics Presentation Service.

The following articles list the details of these default rules and factors to handle these tasks.

Default rules for non-monetary events

Default rules to monitor non-monetary events are available for the following campaigns:

• Compromised Elements

• Login Account Takeover

• Risks on Mobile Device

• Risks on Nme

• Open Banking Management

• PSD2 Beneficiary Management

• PSD2 Payment Account Information

• Follow-up (Near Time)

Compromised Elements

Compromised Elements is a high priority and real-time campaign. It contains rules to check if one of the elements of the non-monetary event has previously been detected, rated to be suspicious, or is related to an account takeover. If any rule matches, the campaign stops processing the rules and sets the response code according to the rule configuration.

The rules inside this campaign decline the event and are executed inline in real time before returning the http response containing the RA response code to the application.

Login Account Takeover

Login Account Takeover is a high priority and real-time campaign. It contains rules to prevent account takeover by checking suspicious elements of a LoginAttempt event and by detecting certain behavior suggesting phishing attacks. If any rule matches, the campaign stops processing the rules and returns the response code immediately to the application.

The rules related to this campaign are executed inline in real time before the RA interface returns the http response containing the Risk Analytics response code.

Risks on Mobile Device

Risks on Mobile Device is a high priority and real-time campaign that contains rules to check the state of the mobile device. The OneSpan Mobile Security Suite CDDC SDK provides device information and the campaign checks factors and values computed from this information. This campaign is executed only for sensitive operations initiated by the corporate banking user from their mobile application. If any rule matches, the campaign stops processing the rules and sets the response code according to the rule configuration.

The rules inside this campaign are executed inline in real time before they return the http response containing an RA response code to the application.

High priority rules of this campaign decline the events, classify them as fraudulent, and generate an alert. Medium priority rules challenge the event and generate an alert, low priority rules challenge the event.

Risks on Nme

Risks on Nme is a high priority and real-time campaign. It contains rules covering fraud risk on sensitive operations, session anomalies, trojan attacks, abnormal corporate user behavior etc. If any rule matches, the campaign stops processing the rules and sets the response code according to the rule configuration.

The rules inside this campaign challenge the corporate banking user with several levels of protection according to the risk. They are executed inline in real time before they return the http response containing an RA response code to the application.

Open Banking Management

Open Banking Management is a low priority and real-time campaign. It helps to implement the third-party provider (TPP) requirements in the context of Open Banking. This campaign handles requirements for non-monetary events received from a TPP application.

A TPP acting as AISP (account information service provider) needs the consent from the PSU end user (who in turn requires a PSU Strong Customer Authentication). This consent must have been granted less than 90 days ago to allow the TPP accessing account information of the PSU.

The rules inside this campaign are executed in real time before they return the http response containing an RA response code to the application.

PSD2 Beneficiary Management

PSD2 Beneficiary Management is a low priority and real-time campaign helping to implement the PSD2 RTS requirements. High-risk priority campaigns must be activated to comply with Article 2 of the PSD2 RTS. This campaign handles the requirements on beneficiary management.

The rules inside this campaign are executed in real time before they return the http response containing an RA response code to the application.

PSD2 Payment Account Information

PSD2 Payment Account Information is a low priority and real-time campaign helping to implement the PSD2 RTS requirements. High-risk priority campaigns must be activated to comply with Article 2 of the PSD2 RTS. This campaign handles the requirements on accessing payment account information. Such requirements include the balance of one or more designated payment accounts, or the payment transactions executed in the last 90 days through one or more designated payment accounts.

The rules inside this campaign are executed in real time before they return the http response that contain an RA response code to the application.

Follow-up (Near Time)

Follow-up is a low priority and near-time campaign. It helps fraud analysts to follow the activity of customers and the state of some elements when a corporate banking user initiates a transaction. Some rules are triggering alerts (Graylisted element), others just indicate that the event matches. Every rule inside this campaign is processed, even if one rule matches and triggers some alerts.

The rules inside this campaign are executed after returning the http response to the application and are useful for triggering alerts.

Default rules for transactions

Default rules to monitor transactions are available for the following campaigns:

• Compromised Elements

• Risks on Payments

• Transaction Risk Analysis - PSD2

• Beneficiary Management

• PSD2 Payment

• Follow-up (Near Time)

Compromised Elements

Compromised Elements is a high priority and real-time campaign. It contains rules to check if one of the elements of the transaction has been previously detected, rated to be suspicious, or is related to an account takeover. Rules contained in this campaign are required to comply with PSD2 RTS, Article 18. Compliance with this article is also achieved with rules contained in the Risks on Payments and Transaction Risk Analysis - PSD2 campaigns. If any rule matches, the campaign stops processing the rules and sets the response code according to the rule configuration.

The rules inside this campaign decline the transaction and are executed inline in real time before returning the http response that contains the RA response code to the application.

Risks on Payments

Risks on Payments is a high priority and real-time campaign. It contains rules covering fraud risk on external payments. Rules contained in this campaign are required to comply with PSD2 RTS, Article 18. Compliance with this article is also achieved with rules contained in the Compromised Elements and Transaction Risk Analysis - PSD2 campaigns. If any rule matches, the campaign stops processing the rules and sets the response code according to the rule configuration.

The rules inside this campaign are executed inline in real time before returning the http response that contains the Risk Analytics response code to the application.

High-risk rules of this campaign decline the transaction, while medium-risk rules challenge the corporate banking user according to the risk.

Transaction Risk Analysis - PSD2

Transaction Risk Analysis - PSD2 is a high priority and real-time campaign. It contains rules covering fraud risk on unusual corporate user behavior that is required to comply with PSD2 RTS, Article 18. Compliance with this article is also achieved with rules contained in the Compromised Elements and Risks on Payments campaigns. If any rule matches, the campaign stops processing the rules and sets the response code according to the rule configuration.

The rules inside this campaign challenge the corporate banking user and are executed inline in real time before they return the http response containing an RA response code to the application.

Beneficiary Management

Beneficiary Management is a medium priority and real-time campaign. It checks certain event elements to detect possible mule accounts. If any rule matches, the campaign stops processing the rules and returns the response code immediately to the application.

The rules inside this campaign are executed in real time before they return the http response that contains an RA response code to the application.

PSD2 Payment

PSD2 Payment is a low priority and real-time campaign helping to implement PSD2 RTS requirements. High-risk priority campaigns and the Compromised Elements, Risks on Payments, and Transaction Risk Analysis - PSD2 campaigns must be activated to comply with Articles 2 and 18 of the PSD2 RTS. This campaign handles requirements and exemptions on Strong Customer Authentication (SCA) when a corporate banking user initiates a payment.

The rules inside the campaign are executed in real time before they return the http response containing the Risk Analytics response code to the application.

The rules of this campaign either exempt the corporate banking user from SCA by accepting the transaction or challenge the user when no exemption applies.

Follow-up (Near Time)

Follow-up is a low priority and near-time campaign. It helps fraud analysts to follow the activity of customers and the state of some elements when a corporate banking user initiates a transaction. Some rules are triggering alerts (Graylisted element), others just indicate that the event matches. Every rule inside this campaign is processed, even if one rule matches and triggers some alerts.

The rules inside this campaign are executed after returning the http response to the application and are useful for triggering alerts.