Rules are a powerful tool if your business needs more control over which orders are prevented or allowed. Your company may have unique business policies that you’d like to implement within Ravelin. For example, you may want to:
- Prevent all orders greater than $100 made from a customer who opened an account within the past 30 days
- Allow all orders from customers who are tagged as 'VIP'
Rules allow you to implement this business logic as specific actions to be taken whenever an order matches the conditions that you define. Ravelin comes with some built-in rules, as well as the ability to create more from the Dashboard.
For each custom rule, you'll select the action (Allow, Prevent, Review) triggered by the rule and define the conditions under which the rule is triggered.
A rule can contain up to eight conditions. A condition is made up of three parts:
- Attribute - The attribute of the order (e.g., the order value or the customer account age)
- Operator - The arithmetic that compares the criteria to the value (e.g., less than or equal to)
- Value - The value you wish to use (e.g., 100.00 GBP or 30 days)
Ravelin currently supports the following attributes for custom rules:
- AVS street check result code
- AVS zip code check result code
- Customer account age
- Customer country
- Customer email provider
- Customer has free email provider
- Customer email has an invalid top level domain
- Customer has disposable email provider
- Customer market name
- Customer market city
- Customer market country
- Customer tag
- Customer watch status
- Customer registration postcode
- Order billing address postcode
- Order start postcode
- Order end postcode
- Order value
- Order time to execution
- Order Seller ID
- Number of distinct billing addresses registered
- Number of billing postcode changes (last 6 months)
- Number of name changes (last 6 months)
- Number of orders (all)
- Number of orders (successful)
- Number of orders (failed)
- Number of order attempts by an email
- Number of order attempts by an order end postcode (all)
- Number of order attempts by card
- Number of order attempts by device
- Number of cards used by an email
- Number of payment registrations (all)
- Number of payment registrations (failed)
- Payment method country of issuance
- Payment method card BIN number
- Payment method card types
- Payment method types
Each order will be evaluated against the rules you have created and processed in a specific order.
- Allow - Rules that allow an order to be processed
- Prevent - Rules that prevent an order from being processed
- Review - Rules that place an order in the review queue
If a payment matches a rule's conditions, the rule's action is performed and no other rules are processed. For example, if an Allow rule is triggered, no Prevent or Review rules will be processed. Allow rules should rarely be implemented as they override Ravelin's default rules.
Within the greater Ravelin system, manual reviews will always take precedence over rules. However, rules will always take precedent over Ravelin fraud scores.
Managing Rules on the Dashboard
You can manage your rules in the Rules section, under the “Manage” tab.
To add a rule, click the Add button in the top right of the table.
For each rule, enter a name for your rule and select the action (Allow, Review Prevent) you want the rule to trigger.
Next, enter the conditions under which you want the rule to trigger. You can enter up to three conditions.
Once you've entered your rule's conditions, you can test your rule by clicking the Test rule button. This will show you the impact the rule has on your customers based on the last 7 days of data. It gives you an indication of whether the criteria used are too strict or not strict enough.
Testing the rule will show you an estimate of what percentage of active customers in the last 7 days would be impacted by the rule. A visual summary of the last action, score distribution and manual reviews associated with the test sample is also show.
You can activate your rule by clicking the Add and enable button.
Only people who are admins or developer role will be able to create rules. This security measure is put in place so that only certain people can build rules, it avoids overlap or rules being created that prevent a large number of customers.