Configuring Fraud Rules
To implement fraud rules for card tokenisation on your website, follow these steps to set it up on the "Fraud Configuration" page.
How to Create a Fraud Rule
- Navigate to the Fraud Configuration page.
- Click on the Create Fraud Rule button.
- Enter a Description for the rule.
- Configure the rule conditions using the collapsible sections (General Rules, IP Based Rules, IP Rate Limiting).
- At least one criterion must be configured for the rule to be valid.
- Select the Action to be taken when the rule is triggered.
- Click Create Fraud Rule to activate the rule.
Rule Configuration
When creating or editing a fraud rule, you will see a form with a Description field at the top, followed by three collapsible sections for configuring rule conditions, and an Action selector at the bottom.
- Description: A text field to describe the purpose of this rule.
- Action: The action to take when this rule is triggered.
Actions
When a fraud rule is triggered, one of the following actions is enforced:
- Reject: The tokenisation is blocked.
- Require 3D Secure: The user must complete additional verification (3D Secure authentication).
- Delay: The tokenisation is delayed for 10 seconds.
- None: No action is taken.
General Rules
The General Rules section contains conditions based on basic transaction data.
Email Filtering
Configure fraud detection based on email patterns using the following match types:
- Exact Match: The rule triggers only if the email exactly matches the specified value.
- Contains: The rule triggers if the email contains a specific substring.
- Regex: Allows pattern-based matching using regular expressions for advanced filtering.
Cardholder Name
Set a rule that triggers when the cardholder name matches the specified value.
Transaction Amount
Set conditions based on the tokenisation amount:
- Equals: The rule applies when the tokenisation amount exactly matches the specified value.
- Less Than: The rule applies when the tokenisation amount is less than the specified value.
- Greater Than: The rule applies when the tokenisation amount is greater than the specified value.
Card Type
Set fraud rules based on specific card types:
- DEBIT: The rule triggers for debit card transactions.
- CREDIT: The rule triggers for credit card transactions.
Block Empty User Agent
A toggle option to block tokenisation requests with empty or missing user-agent values, which is a common trait in fraudulent activity.
IP Based Rules
The IP Based Rules section contains conditions based on network information.
IP Address List
Configure fraud detection based on source IP addresses. Enter a comma-separated list of IP addresses that will trigger this rule when a request originates from any IP in the list.
Country-Based IP Filtering
Configure fraud detection based on the country of origin using a dual-list selector interface.
Rule Type:
- Contains: The rule triggers when a tokenisation request originates from any of the selected countries.
- Does not contain: The rule triggers when a tokenisation request does not originate from any of the selected countries.
Country Selection:
- Use the Available Countries list on the left to find countries (searchable).
- Use the arrow buttons to move one or more countries to the Selected Countries list on the right.
- Use the double arrow buttons to move all countries at once.
IP Rate Limiting
The IP Rate Limiting section allows you to limit the number of tokenisation requests from a single IP address within a time window.
Enabled
Toggle to enable or disable IP rate limiting for this rule.
Time Window
Select the time period over which to count requests:
- 1 minute
- 10 minutes
- 1 hour
- 10 hours
- 24 hours
Limit
Set the maximum number of requests allowed from a single IP address within the selected time window. When this limit is exceeded, the configured action will be triggered.
Multiple Fraud Rules Match the Input Parameters
When multiple fraud rules match the input parameters, the system determines the final action based on a predefined priority order. The actions are applied in the following order of precedence:
- Reject - If any matching rule dictates a rejection, the tokenisation is blocked immediately.
- Require 3D Secure - If no rule enforces a rejection but at least one requires 3D Secure, the user must complete additional verification.
- Delay - If neither of the above applies, but a rule specifies a delay, the tokenisation is paused for 10 seconds.
- None - If none of the matched rules enforce an action, the tokenisation proceeds without restriction.
This ensures that the strictest applicable action is enforced first, preventing fraudulent activity while allowing legitimate transactions to proceed with appropriate security measures.