Follow

Risk Suite 0.9.3

optile's Risk Suite offers functionality to help you prevent fraud and manage your risk. Our Risk Suite is continuously evolving and currently you can choose to block specific transactions when those transactions meet certain conditions. These conditions could be Simple Conditions, Aggregate Conditions or a combination of conditions (i.e., conditions combined with AND in a single rule).

What’s new?

v0.9.3                 Referral lists

 

Creating Risk Rules

Until our risk suite user interface is ready, we offer a simple and efficient process of defining/changing risk rules. This is achieved by sending us these rules/changes via the ‘Risk Rule Configuration Request' excel file to support@optile.net. If no applicable environment is specified (sandbox/live), we apply the rules to sandbox by default.

Our support team will check the rules for logic and organize the configuration of the risk rules on your behalf.  A confirmation email with the risk rule IDs will be returned to once the rules have been instated on optile’s systems. Modifying rules can be also done by sending your Risk Rule Configuration Request excel file to optile which contains the risk rule IDs that need deletion or modification. 

 

Simple Rule Conditions

A simple condition evaluates the transaction in its own scope, i.e., without considering information that does not directly relate to the current transaction.  Simple conditions block a transaction if a parameter of the transaction (a dimension) has (or does not have) the specified value. For example:

  • Block if IP Country has value ‘US’
  • Block if IP Country does not have the same value as Issuing Country
  • Block if Email Address contains ‘noreply’

Dimensions for simple conditions                                                                                            

  1. IP Address: the end customer's IP address.
  2. IP Country: the country where the end customer’s IP address emanates.
  3. IP Continent: the continent where the end customer’s IP address emanates.
  4. BIN: the Bank Identification Number which is the first 6 digits of a credit card.
  5. Issuing Country: the country where the credit card was issued.
  6. E-Mail Address: the full e-mail address of your end customer.
  7. E-Mail Local part: the first part of the e-mail address before the "@" sign.
  8. E-Mail Domain: the part of the e-mail address after the "@" sign.
  9. Division: merchant’s division (shop) code.
  10. Transaction Country: the country specified in the transaction request transmitted to optile

Referral Lists

Instead of specifying just one value, a list can be created allowing a check of a dimension against multiple values. This feature gives you the opportunity to ‘blacklist’ or ‘whitelist’ a number of values with a single rule.

 

Example of simple conditions:

  1. Block if value of [Dimension] 'has' or 'has not' value "X" - examples:
    • [IP Country] 'has not' value "Germany". This rule matches and blocks all end customers with an IP address not from Germany.
    • [E-Mail Domain] 'has' value "hotmail.com". This rule matches and blocks all end customers using an email address ending in "@hotmail.com".
  2. Block if value of [Dimension] 'has' or 'has not' the same value as [Dimension] - example:
    • [IP Country] 'has not' the same value as [Issuing Country]. This rule matches and blocks all transactions where the credit card is issued in a country other than the GeoIP location of the end customer.
  3. Block if value of [Dimension] 'contains' or 'does not contain' substring "X" - example:
    • [E-Mail Domain] 'contains' substring "yahoo.". This rule matches and blocks all end customers using a yahoo email address, for example "@yahoo.de", "@yahoo.com" and "@yahoo.fr" (among others).
  1. Block if value of [Dimension] is/is not in list [referral list] – example:
  • [IP Country] is not in list ‘allowed_ip_countries’

 

 

Aggregate Conditions

 An Aggregate condition checks the current transaction in the context of past transactions. There are two types of aggregated conditions:

Aggregated condition type 1

Block a transaction if there were more than [N] transactions for the same 'Aggregation Parameter' in 'Time Period'. For example:

  • Block if there were 3 or more transactions for the same Payment Account in the last 24 hours.
  • Block if there were 15 or more transactions for the same Customer number in the last 30 days.

 You can create your type 1 aggregate condition using one of the following four aggregate dimensions (1-4) below and a time period:

  1. Card/Account number
  2. Customer Number
  3. Customer IP
  4. E-Mail address

 

Aggregate condition type 2

Block a transaction if there were more than [N] different values for a transaction parameter (see dimensions for aggregated conditions below) for the same aggregation dimension in given period. For example,

  • Block if there are more than 3 different Customer IP Addresses for the same Payment Account in the last 24 hours.
  • Block if there are more than 7 different Customer Numbers for the same Payment Account in the last 30 days.
  • Block if thereare more than 5 different Customer IP Addresses for the same Payment Account in the last 14 days.
  • Block if there are more than 5 different Customer Numbers for the same Customer IP address in the last 1 day.

You can create your type 2 aggregate conditions using the eleven dimensions below and a time period:

Dimensions for type 2 aggregated parameters

  1. IP Address - the end customer's IP address.
  2. Card / Account Number
  3. Customer Number
  4. E-Mail Address - The full e-mail address of your end customer.
  5. IP Country - the country where the end customer’s IP address emanates
  6. IP Continent - The continent where the end customer’s IP address emanates
  7. BIN - the Bank Identification Number which is the first 6 digits of a credit card
  8. Issuing Country - The country where the credit card was issued
  9. E-Mail Domain - the part of the e-mail address after the "@"
  10. Account Expiration Date
  11. Transaction Country - The country specified in the transaction itself 

 

Time period is a configurable period for transaction aggregation. It could be "the last 30 days" or "the last 12 hours"; it is always evaluated with regards to the exact time that the transaction was attempted.

 

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request

Comments