Default rules for corporate banking in Risk Analytics
OneSpan Risk Analytics for Corporate Banking is pre-configured with a number of default rules and factors for
- 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 
Revised European Payment Service Directive (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
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.
| Division | Default Rules | Description |
|---|---|---|
| Blacklisted Element (High) | An element is identified as fraudulent. When detected in an event, Risk Analytics declines the event and tags it as fraudulent. | |
| Blacklisted Beneficiary Country (High) | ||
| Blacklisted Beneficiary IBAN (High) | ||
| Blacklisted Cookie (High) | ||
| Blacklisted Cookie ID (High) | ||
| Blacklisted |
||
| Blacklisted Device Fingerprint (High) | ||
| Blacklisted Device ID (High) | ||
| Blacklisted GIS Country (High) | ||
| Blacklisted HTTP Header (High) | ||
| Blacklisted IP Address (High) | ||
| Blacklisted IP Country (High) | ||
| Blacklisted IP ISP (High) | ||
| Blacklisted Referrer (High) | ||
| Blacklisted TPP Element (High) | A TPP element is identified as fraudulent. When detected in an event, Risk Analytics declines the event and tags it as fraudulent. | |
| Blacklisted TPP (High) | ||
| Blacklisted TPP IP Address (High) | ||
| Blacklisted TPP PSU Device (High) |
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.
| Division | Default Rules | Description |
|---|---|---|
| Phishing Attacks (High) | This division contains default rules to detect phishing attack behavior. If one of the rules matches, the event is challenged and an alert is triggered. | |
| High Risk Phishing (High) | Triggered when a new user device and new user ISP have been used, and the ISP is graylisted. | |
| Medium Risk Phishing (Medium) | Triggered when a new bank device and new bank ISP have been used. | |
| Low Risk Phishing (Low) | Triggered when a new user device and new user ISP have been used. The ISP is whitelisted. | |
| 2 Different IP Countries in 1 hour (Low) | Triggered when the |
|
| Suspicious Device (Medium) | This division contains default rules to detect suspicious device activities. For such activities the login is challenged, and an alert is triggered. | |
| New Device for |
Triggered when a |
|
| New Device for device having many |
Triggered when a |
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
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.
| Division | Default Rules | Description |
|---|---|---|
| Mobile Anomalies (High) | Rules detecting anomalies with information from the CDDC SDK. | |
| Debugger Attached (High) | Detects if a debugger is attached to the application. | |
| Hooking Framework (High) | Detects a hooking framework. | |
| Libinject (High) | Detects a library injection. | |
| Native Code Hook (High) | Detects a native code hook. | |
| RASP Mismatch (High) | Detects if RASP is no longer active. | |
| Repackaged App (High) | Detects if the application has been repackaged. | |
| Untrusted Screen (High) | Detects if the screen attached to the application is untrusted. | |
| Screenshot Detected (Medium) | Detects if a screenshot is applied during the operation. | |
| Untrusted Keyboard (Medium) | Detects if the keyboard attached to the application is untrusted. | |
| Rooted Device (Low) | Detects if the device is rooted. | |
| Rooting High Probability (Low) | Detects the degree of probability of the device being rooted. | |
| Secure Element non supported (Low) | Detects if secure element is supported or not. |
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
The rules inside this campaign challenge the
| Division | Default Rules | Description |
|---|---|---|
| Session Anomalies (High) | This division contains default rules to detect potential session anomalies. | |
| Fast Navigation (Medium) | Detects if the time lapse between requests is suspect. | |
| Short Time between Sessions (Medium) | Detects suspect request sequences. | |
| Many User Requests (Low) | Detects suspect session behavior. | |
| Trojan Attacks (Medium) | This division contains default rules to detect potential Trojan attacks. These rules trigger several alerts when they match. | |
| Device Change in Session (High) | Detects if a device changed during the session. | |
| ISP Change in Session with New ISP (High) | Detects if an ISP changed during the session and that is new for the |
|
| IP Change in Session (Medium) | Detects if an IP address changed during the ongoing session. | |
| ISP Change in Session (Low) | Detects if an IP ISP changed during the ongoing session. | |
| Cross |
This division contains rules detecting anomalies for multiple |
|
| More than 3 |
||
| More than 3 |
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 Payment service user 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.
| Division | Default Rules | Description |
|---|---|---|
| Consent Management (High) | Group of Open Banking rules managing Strong Customer Authentication (SCA) on PSU consent. | |
| SCA on PSU Consent Initiation (High) | Rule to trigger SCA when PSU gives consent to access its accounts. | |
| Decline Account Access without Consent (Low) | Rule that declines access to accounts when the PSU denies consent with SCA within the last 90 days. |
PSD2 Beneficiary Management
PSD2 Beneficiary Management is a low priority and real-time campaign helping to implement the PSD2 RTS Regulatory Technical Standards (RTS) requirements under the revised European Payment Service Directive (PSD2). 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.
| Division | Default Rules | Description |
|---|---|---|
| SCA Obligation (Medium) | Group of PSD2 rules that handle beneficiary management events that are not exempt from Strong Customer Authentication (SCA). | |
| SCA on Beneficiary Management (High) | Checks if SCA is required when the |
|
| Trust management (Low) | Group of PSD2 rules that manage the trust level of a beneficiary. | |
| Trust Beneficiary (High) | Rule to trust a beneficiary when a |
|
| Untrust Beneficiary (High) | Rule to untrust a beneficiary when the |
PSD2 Payment Account Information
PSD2 Payment Account Information is a low priority and real-time campaign helping to implement the PSD2 RTS Regulatory Technical Standards (RTS) requirements under the revised European Payment Service Directive (PSD2). 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.
| Division | Default Rules | Description |
|---|---|---|
| SCA Exemption (Medium) | Group of PSD2 rules that accept Strong Customer Authentication (SCA) exemption. | |
| Exemption on Check Balance (High) |
Exemption on accessing the balance of a payment account. (PSD2 RTS Article 10.1 (a).) Checks if a check balance event validated by a successful strong customer authentication has previously been received in a non-risky context in the last 90 days. Remark: Article 10.1 (a) is managed like article 10.1 (b): exempted if SCA has taken place in the last 90 days, as it is not possible to have a history rule monitoring an unlimited period. |
|
| Exemption on Check Balance Detail (High) |
Exemption on accessing the balance detail of a payment account. (PSD2 RTS Article 10.1 (a).) Checks if a check balance detail event validated by a successful strong customer authentication has previously been received in a non-risky context in the last 90 days. Remark: Article 10.1 (a) is managed like article 10.1 (b): exempted if SCA has taken place in the last 90 days, as it is not possible to have a history rule monitoring an unlimited period. |
|
| Exemption on Getting Payment Transactions (High) | Exemption on accessing payment transactions executed in the last 90 days. (PSD2 RTS Article 10.1 (b).) | |
| SCA Obligation (Low) | Group of PSD2 rules that handle payment account information that are not exempt from SCA. | |
| No Exemption (High) | Default rule that challenges the customer for applying SCA, when payment account information is not exempt from SCA. |
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
The rules inside this campaign are executed after returning the http response to the application and are useful for triggering alerts.
| Division | Default Rules | Description |
|---|---|---|
| Graylisted element (High) | This division contains default rules to detect potential fraud or risky elements. Used for follow-up. | |
| Graylisted Beneficiary Country (Medium) | ||
| Graylisted Beneficiary IBAN (Medium) | ||
| Graylisted Cookie (Medium) | ||
| Graylisted Cookie ID (Medium) | ||
| Graylisted |
||
| Graylisted Device Fingerprint (Medium) | ||
| Graylisted Device ID (Medium) | ||
| Graylisted GIS Country (Medium) | ||
| Graylisted HTTP Header (Medium) | ||
| Graylisted IP Address (Medium) | ||
| Graylisted IP Country (Medium) | ||
| Graylisted IP ISP (Medium) | ||
| Graylisted Referrer (Medium) | ||
| Whitelisted element (Low) | This division contains default rules to trace elements identified as secure. Those rules do not trigger any actions. | |
| Whitelisted Beneficiary Country (High) | ||
| Whitelisted Beneficiary IBAN (High) | ||
| Whitelisted Cookie (High) | ||
| Whitelisted Cookie ID (High) | ||
| Whitelisted |
||
| Whitelisted Device Fingerprint (High) | ||
| Whitelisted Device ID (High) | ||
| Whitelisted GIS Country (High) | ||
| Whitelisted HTTP Header (High) | ||
| Whitelisted IP Address (High) | ||
| Whitelisted IP Country (High) | ||
| Whitelisted IP ISP (High) | ||
| Whitelisted Referrer (High) |
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 Regulatory Technical Standards (RTS) requirements under the revised European Payment Service Directive (PSD2)., Article 18. Compliance with this article is also achieved with rules contained in the
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.
| Division | Default Rules | Description |
|---|---|---|
| Blacklisted element (High) | An element is identified as fraudulent. When detected in an event, Risk Analytics declines the event and tags it as fraudulent. | |
| Blacklisted Beneficiary Country (High) | ||
| Blacklisted Beneficiary IBAN (High) | ||
| Blacklisted Cookie (High) | ||
| Blacklisted Cookie ID (High) | ||
| Blacklisted |
||
| Blacklisted Device - Mobile (High) | ||
| Blacklisted Device - Web (High) | ||
| Blacklisted GIS Country (High) | ||
| Blacklisted HTTP Header (High) | ||
| Blacklisted IP Address (High) | ||
| Blacklisted IP Country (High) | ||
| Blacklisted IP ISP (High) | ||
| Blacklisted Referrer (High) | ||
| Blacklisted TPP Element (High) | A TPP element is identified as fraudulent. When detected in an event, Risk Analytics declines the event and tags it as fraudulent. | |
| Blacklisted TPP (High) | ||
| Blacklisted TPP IP Address (High) | ||
| Blacklisted TPP PSU Device (High) |
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 Regulatory Technical Standards (RTS) requirements under the revised European Payment Service Directive (PSD2)., Article 18. Compliance with this article is also achieved with rules contained in the
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
| Division | Default Rules | Description |
|---|---|---|
| Model Anomalies (High) |
This division contains rules that detect anomalies based on the machine learning model. Remark: This division could be activated when enough labeled data have been extracted to train the machine learning model. See Corporate banking factors for more details. |
|
| Critical Risk Score (High) | Declines a transaction with a critical score. | |
| High Risk Score (Medium) | Challenges a transaction with a high score. | |
| Trojan Attacks (High) | This division contains default rules to detect Trojan attacks on transactions. | |
| Change of Device in Session & not Trusted validation (High) | Detects if a device changed during the session for an event which is not a transaction validation from a trusted device. | |
| Change of IP in session with New IP for this |
Detects if the IP changed during the session and is new for this |
|
| Change of ISP in session with New ISP for this |
Detects if the ISP changed during the session and is new for this |
|
| Phishing Attacks (Medium) | This division contains default rules to detect phishing attacks on transactions. | |
| High Risk Phishing (High) | Detects new devices and ISP across all |
|
| Medium Risk Phishing (Medium) | Detects transaction with a high amount from a new device with a new ISP in the graylist. | |
| Low Risk Phishing (Low) | Detects transaction from a new device with a new ISP that is not in the whitelist. | |
| Sample – Cross- |
Rules detecting anomalies by comparing activities of multiple |
|
| More than 3 |
Checks if more than three |
|
| Sample – Geolocation (Low) | Rules detecting geolocation anomalies. | |
| 2 diff IP Countries in 30 minutes (High) | ||
| 2 diff IP Countries in 30 minutes (Medium) |
Transaction Risk Analysis - PSD2
Transaction Risk Analysis - PSD2 is a high priority and real-time campaign. It contains rules covering fraud risk on unusual Regulatory Technical Standards (RTS) requirements under the revised European Payment Service Directive (PSD2)., Article 18. Compliance with this article is also achieved with rules contained in the
The rules inside this campaign challenge the
| Division | Default Rules | Description |
|---|---|---|
| Unusual Behavior (High) | Group of PSD2 rules that force Strong Customer Authentication (SCA) on online payments based on Article 2 and Article 18. | |
| New |
Detects the first session in which the |
|
| Abnormal Location (IP Country) (Low) | Detects the first session by this |
|
| Abnormal Location (ISP) (Low) | Detects the first session in which the |
|
| High risk location of the payee (Low) | Checks if the bank country of the payee is on the whitelist. |
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.
| Division | Default Rules | Description |
|---|---|---|
| Possible Mule Accounts (Low) | This division contains default rules to analyze account activity and detect potential mule accounts. | |
| High Risk Mule Account (High) | ||
| Medium Risk Mule Account (Medium) | ||
| Low Risk Mule Account (Low) |
PSD2 Payment
PSD2 Payment is a low priority and real-time campaign helping to implement PSD2 RTS Regulatory Technical Standards (RTS) requirements under the revised European Payment Service Directive (PSD2). requirements. High-risk priority campaigns and the
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
| Division | Default Rules | Description |
|---|---|---|
| Low Fraud Rate SCA Exemption (High) |
This division contains a group of PSD2 rules that allow Strong Customer Authentication (SCA) exemption when the overall fraud rate reported by the payment service provider allows SCA exemption for transactions below a particular Exemption Threshold Value (ETV). (PSD2 RTS Article 18.2 (b)). Remark: Only one of the rules of this division must be activated if the overall fraud rate has been reported and the corresponding ETV defined. |
|
| Exemption on transaction value <= high ETV (High) | SCA exemption if the transaction amount is equal or lower than the high ETV (500€). | |
| Exemption on transaction value <= medium ETV (Medium) | SCA exemption if the transaction amount is equal or lower than the medium ETV (250€). | |
| Exemption on transaction value <= low ETV (Low) | SCA exemption if the transaction amount is equal or lower than the low ETV (100€). | |
| Standard SCA Exemption (Medium) | Group of PSD2 rules that allow SCA exemption when the low fraud rate SCA exemption cannot apply (unknown fraud rate and ETV). Exemptions do not apply when creating recurring payments. | |
| Exemption on Recurring subsequent transaction (High) | Exemption on recurring subsequent payment transactions. (PSD2 RTS Article 14.2.) | |
| Exemption on Transfer to Same Customer (High) | Exemption when payer and beneficiary are the same person. (PSD2 RTS Article 15.) | |
| Exemption on Trusted Beneficiary (Medium) | Exemption when the beneficiary is in the trusted list (SCA was applied when the payer created or amended the beneficiary). (PSD2 RTS Article 13.2.) | |
| Exemption on Low value transaction and Low amount sum (Low) | Exemption when the amount of the payment transaction does not exceed €30 and when the cumulative amount since the last SCA does not exceed €100. Note that the last SCA must be in the last 90 days. (PSD2 RTS Article 16 (a) and (b).) | |
| Exemption on Low value transaction and Low frequency (Low) | Exemption when the amount of the payment transaction does not exceed €30 and when the number of previous payment transactions since the last SCA does not exceed 5. Note that the last SCA must be in the last 90 days. (PSD2 RTS Article 16 (a) and (c).) | |
| SCA Obligation (Low) | This division contains a group of PSD2 rules handling payment transactions that are not exempt from SCA. | |
| SCA on Recurring transaction initiation (High) | This rule challenges the |
|
| No Exemption (Medium) | Default rule that challenges the |
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
The rules inside this campaign are executed after returning the http response to the application and are useful for triggering alerts.
| Division | Default Rules | Description |
|---|---|---|
| Graylisted element (High) | This division contains default rules to detect potential fraud or risky elements. Used for follow-up. | |
| Graylisted Beneficiary Country (Medium) | ||
| Graylisted Beneficiary IBAN (Medium) | ||
| Graylisted Cookie (Medium) | ||
| Graylisted Cookie ID (Medium) | ||
| Graylisted |
||
| Graylisted Device Fingerprint (Medium) | ||
| Graylisted Device ID (Medium) | ||
| Graylisted GIS Country (Medium) | ||
| Graylisted HTTP Header (Medium) | ||
| Graylisted IP Address (Medium) | ||
| Graylisted IP Country (Medium) | ||
| Graylisted IP ISP (Medium) | ||
| Graylisted Referrer (Medium) | ||
| Whitelisted element (Low) | This division contains default rules to trace elements identified as secure. Those rules do not trigger any actions. | |
| Whitelisted Beneficiary Country (High) | ||
| Whitelisted Beneficiary IBAN (High) | ||
| Whitelisted Cookie (High) | ||
| Whitelisted Cookie ID (High) | ||
| Whitelisted |
||
| Whitelisted Device Fingerprint (High) | ||
| Whitelisted Device ID (High) | ||
| Whitelisted GIS Country (High) | ||
| Whitelisted HTTP Header (High) | ||
| Whitelisted IP Address (High) | ||
| Whitelisted IP Country (High) | ||
| Whitelisted IP ISP (High) | ||
| Whitelisted Referrer (High) |