Default rules for digital banking in Risk Analytics

OneSpan Risk Analytics for Digital Banking is pre-configured with a number of default rules and factors for digital 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 digital banking events such as changing profiles, managing beneficiaries, and tracking fund transfers.

The digital banking template also includes rules to comply with Regulatory Technical Standards (RTS) requirements under PSD2Closed 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 Digital 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 digital banking rules of Risk Analytics to your application flows, navigate to the Design Rules & Actions page in OneSpan Risk Analytics Presentation ServiceClosed A highly dynamic web interface that provides webpages for the user to intuitively interact with Risk Analytics. It is a Microsoft .NET 4.7.2 ASP.NET application hosted inside Microsoft Internet Information Services (IIS)..

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
  • Adaptive Authentication
  • Open Banking Management
  • PSD2 Beneficiary Management
  • PSD2 Payment Account Information
  • Adaptive Authentication List Management (Near Time)
  • 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.

Divisions and default rules for Compromised Elements (real time)
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 Customer (High)  
  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.

Divisions and default rules for Login Account Takeover (real time)
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 customer location has changed during the last hour.
     
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 customer having many devices (Low) Triggered when a customer has registered a new device but they already have 10 or more devices registered.
  New Device for device having many customers (Low) Triggered when a customer registers a new device but this device is already used by more than 10 users.

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

Divisions and default rules for Risks on Mobile Device (real time)
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 customer 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 retail 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.

Divisions and default rules for Risks on Nme (real time)
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 customer.
  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 Customer Anomalies (Low)   This division contains rules detecting anomalies for multiple customer activities.
  More than 3 customers using the same IP in 1 day (Medium)  
  More than 3 customers using same device in 1 day (Medium)  

Intelligent Adaptive Authentication

Intelligent Adaptive Authentication is a medium priority and real-time campaign. It contains business rules that handle the OneSpan Intelligent Adaptive Authentication service. Rules of this campaign challenge the retail user with the appropriate protection type according to the risk.

Divisions and default rules for Intelligent Adaptive Authentication (real time)
Division Default Rules Description
CheckBalance Management (High)   This division contains default rules that manage the check balance event (the first event of the OneSpan Intelligent Adaptive Authentication demo) and trigger a strong authentication, if required.
  Known User Device (Medium) Accepts the check balance without authentication when the device is whitelisted.
  New User Device (Low) Triggers a strong authentication when the session uses a new device for the customer.
     
Mobile Login Compromised Device (High)   This division checks the mobile state when the user is trying to log in from a mobile application.
  Application repackaged detected (High) Detects if the application has been repackaged.
  Library injection detected (High) Detects a library injection.
  Hooking framework detected (Medium) Detects a hooking framework.
  Rooted device detected (Medium) Detects if the device is rooted.
  Secure element not supported (Low) Detects if secure element is supported or not.
     
Web Logon Graylisted (Medium)   This division manages login attempts containing graylisted elements.
  Gray listed Customer (High)  
  Gray listed Device (High)  
  Gray listed IP (High)  
  Gray listed ISP (Medium)  
  Gray listed Referrer (Medium)  
  Gray listed Cookie (Low)  
  Gray listed Cookie ID (Low)  

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

Divisions and default rules for Open Banking Management (real time)
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 RTSClosed 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.

Divisions and default rules for PSD2 Beneficiary Management (real time)
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 customer creates or amends a beneficiary from the list of trusted beneficiaries. (PSD2 RTS Article 13.1.)
     
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 customer creates or amends a beneficiary with successful SCA.
  Untrust Beneficiary (High) Rule to untrust a beneficiary when the customer removes the beneficiary from the list of trusted beneficiaries.

PSD2 Payment Account Information

PSD2 Payment Account Information is a low priority and real-time campaign helping to implement the PSD2 RTSClosed 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.

Divisions and default rules for PSD2 Payment Account Information (real time)
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.

Intelligent Adaptive Authentication List Management (Near Time)

Intelligent Adaptive Authentication List Management is a low priority and near-time campaign. It manages hotlists in the context of the OneSpan Intelligent Adaptive Authentication service. The rules allow to move elements in hotlists based on pre-defined workflow actions. Every rule inside this campaign is processed, even if a rule matches and triggers actions.

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

Divisions and default rules for Intelligent Adaptive Authentication List Management (Near Time)
Division Default Rules Description
Gray List Management (Low)   This division contains default rules to add a device to or remove a device from a graylist.
  Add to Gray List (Low) This rule adds a device to the graylist when the login failed and the device is not blacklisted.
  Remove from Gray List (Low) This rule moves a device from the graylist to the whitelist when the login succeeds.

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

Divisions and default rules for Follow-up (Near Time)
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 Customer (Medium)  
  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 Customer (High)  
  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
  • Adaptive Authentication Mobile Payments
  • Adaptive Authentication Web Payments
  • 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 RTSClosed 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 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.

Divisions and default rules for Compromised Elements (real time)
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 Customer (High)  
  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 RTSClosed 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 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 retail banking user according to the risk.

Divisions and default rules for Risks on Payments (real time)
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 Digital 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 customer (Medium) Detects if the IP changed during the session and is new for this customer.
  Change of ISP in session with New ISP for this customer (Low) Detects if the ISP changed during the session and is new for thiscustomer.
     
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 customers.
  First transaction to beneficiary and several countries in the last hour (Medium) Detects a transaction to a new beneficiary from a customer that moved between several countries in the last hour.
  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 - Transaction Anomalies (Medium)   Rules detecting anomalies in transactions of amounts greater than 1,000 € to a new beneficiary for this customer.
  Large Amount Critical Risk (High) Checks if a large amount is transferred during the night and if a second customer has transferred money to the same beneficiary during the previous hour.
  Large Amount High Risk (Medium) Checks if a large amount is transferred from a new device with a new ISP to a risky country.
  Large Amount to new Bank beneficiary (Medium) Checks if it is the first time a transaction is sent to the new beneficiary (several customers).
  Large Amount Medium Risk (Low) Checks if a large amount is transferred to a new beneficiary not linked to more than three accounts.
Sample – Cross-Customer Anomalies (Low)   Rules detecting anomalies by comparing activities of multiple customers.
  More than 3 customers using same IP in 1 day (Medium) Checks if more than three customers use the same IP in one day for a non-anonymous proxy.
  More than 3 customers using same device in 1 day (Medium) Checks if more than three customers use the same device in one day for non-anonymous proxy.
     
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 customer behavior that is required to comply with PSD2 RTSClosed 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 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 retail banking user and are executed inline in real time before they return the http response containing an RA response code to the application.

Divisions and default rules for Transaction Risk Analysis - PSD2 (real time)
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 Customer Device (Medium) Detects the first session in which the customer uses this device.
  Abnormal Location (IP Country) (Low) Detects the first session by this customer for this IP Country.
  Abnormal Location (ISP) (Low) Detects the first session in which the customer uses this Internet Service Provider (ISP).
  High risk location of the payee (Low) Checks if the bank country of the payee is on the whitelist.

Intelligent Adaptive Authentication Mobile Payments

Intelligent Adaptive Authentication Mobile Payments is a medium priority and real-time campaign. It contains business rules that handle the OneSpan Intelligent Adaptive Authentication service for transactions initiated from a mobile application. If any rule matches, the campaign stops processing the rules and sets the response code according to the rule configuration. Risk Analytics does not execute this campaign if any one of the rules of the previous campaigns has declined the transaction.

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

Divisions and default rules for Intelligent Adaptive Authentication Mobile Payments (real time)
Division Default Rules Description
Compromised Device high amount (High)   This division contains rules that check CDDC elements if the amount is greater than or equal to a defined threshold (default value: 100 €).
  Hooking framework detected high amount (High) Detects a hooking framework for high amount transactions.
  Rooted device high amount (High) Detects if the device is rooted for high amount transactions.
  Application repackaged detected high amount (Medium) Detects if the applications has been repackaged for high amount transactions.
  Library injection detected high amount (Medium) Detects a library injection for high amount transactions.
  Secure element not supported high amount (Low) Detects if secure element is supported for high amount transactions.
     
Compromised Device (Medium)   This division contains rules that check CDDC elements.
  Hooking framework detected (High) Detects a hooking framework.
  Rooted device (High) Detects if the device is rooted.
  Application repackaged detected (Medium) Detects if the applications has been repackaged.
  Library injection detected (Medium) Detects a library injection.
  Secure element not supported (Low) Detects if secure element is supported.

Intelligent Adaptive Authentication Web Payments

Intelligent Adaptive Authentication Web Payments is a medium priority and real-time campaign. It containing business rules that handle the OneSpan Intelligent Adaptive Authentication service for transactions initiated from a web application. If any rule matches, the campaign stops processing the rules and sets the response code according to the rule configuration. Risk Analytics does not execute this campaign if any one of the rules of the previous campaigns has declined the transaction.

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

Divisions and default rules for Intelligent Adaptive Authentication Web Payments (real time)
Division Default Rules Description
Challenged TXN (High)   This division contains rules that challenge the retail banking user with the appropriate protection type, according to the risk (no PIN, fingerprint, face recognition).
  TXN from RISKY Country (High) Detects that the customer initiates the transaction from a risky country.
  Very low amount (High) Asks for basic authentication if the transaction handles a low amount.
  Medium amount (Medium) Asks for fingerprint authentication if transaction handles a medium amount.
  High amount (Low) Asks for face recognition authentication if the transaction handles a high amount.

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.

Divisions and default rules for Beneficiary Management (real time)
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 RTSClosed Regulatory Technical Standards (RTS) requirements under the revised European Payment Service Directive (PSD2). 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 retail 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 retail banking user from SCA by accepting the transaction or challenge the user when no exemption applies.

Divisions and default rules for PSD2 Payment (real time)
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 customer for applying SCA when a recurring transaction is created or amended. (PSD2 RTS Article 14.1.)
  No Exemption (Medium) Default rule that challenges the customer for applying SCA when payment transaction 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 retail 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.

Divisions and default rules for Follow-up (Near Time)
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 Customer (Medium)  
  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 Customer (High)  
  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)