Skip to main content

Configuring Fraud Rules

To implement the Fraud rules for card tokenisation on your website, follow these steps to set it up on the "Fraud configuration" page.

Fraud Rules

How to Create a Fraud Rule​

  1. Navigate to the Fraud Configuration page.
  2. Click on the Create Fraud Rule button.
  3. Define the conditions based on email, tokenisation amount, or card type.
  4. Select the action to be taken when the rule is triggered.
  5. Click Create Fraud Rule to activate the rule.

1. Email Filtering​

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

2. Transaction Amount​

The fraud rule can specify conditions based on the tokenisation amount:

  • Equals: The rule applies when the tokenisation amount exactly matches the specified value.
  • Greater Than / Less Than: Can be extended to apply rules based on tokenisation ranges.

3. Card Type​

To set fraud rules based on specific card types (e.g., DEBIT or CREDIT).

4. User Agent Filtering​

A toggle option allows blocking tokenisation with empty or missing user-agent values, which is a common trait in fraudulent activity.

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.

Once a rule is created, it is applied to incoming tokenisation to mitigate fraudulent activity effectively.

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:

  1. Reject – If any matching rule dictates a rejection, the tokenization is blocked immediately.
  2. Require 3D Secure – If no rule enforces a rejection but at least one requires 3D Secure, the user must complete additional verification.
  3. Delay – If neither of the above applies, but a rule specifies a delay, the tokenization is paused for 10 seconds.
  4. None – If none of the matched rules enforce an action, the tokenization 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.