Skip to main content

Antifraud

Rules Menu Overview​

This section provides a quick guide to each element you see on that screen.

  1. Search Bar - Located at the top-left, this allows you to filter the list of rules by typing a rule name or other keywords.
  2. “New Rule” Button - Located at the top-right. Clicking this opens a form to create a new anti-fraud rule (where you define scope, conditions, action, weight, etc.).
  3. Rules Table: The main area displays a table of all configured rules. Each row corresponds to one rule. The columns include:
    • Name
      • The label given to the rule. This helps you easily identify the rule’s purpose or logic.
    • Level Type
      • Indicates the scope of the rule—“Merchant,” “Acquirer,” or “System.”
      • For example, if it says Merchant, the rule affects only a specific merchant’s transactions, but for any acquirer..
      • If it says Acquirer, the rule applies to all merchants under that acquirer.
      • System would apply globally to all transactions in the platform.
    • Level Name
      • Shows which specific merchant or acquirer this rule is tied to.
      • E.g., if Level Type is “Acquirer” and Level Name is “acquire_1,” it means the rule applies to all merchants under the “acquire_1” acquirer.
    • Status
      • Indicates whether the rule is currently Active or not.
      • “Active” means the rule is in effect and will be evaluated for every incoming transaction that falls under its scope.
    • Action
      • The automated response the system performs if this rule is triggered. Common examples:
        • decline (reject the transaction)
        • 3ds (force a 3D Secure authentication)
        • alert (notify the fraud team without blocking)
        • decline + alert (notify the fraud team and reject the transaction)
      • This is determined by how you configured the rule’s final outcome.
    • Rule Weight
      • A numeric value that represents the importance of the rule.
      • A higher weight typically means a higher level of risk.
      • System sums the weights of all triggered rules of the same Level Type, you might define a global or acquirer-level score threshold to decide whether to block or further inspect the transaction.
    • Level Score
      • This is the threshold used in conjunction with the Rule Weight. If a transaction’s combined rule weight meets or exceeds the “Level Score,” it can trigger additional actions such as blocking or further review.
      • In some rows, you may see “Add score,” which indicates no score threshold has been set yet for that Level Type (System, Merchant, Acquirer). Where a numeric value is visible (e.g., “100 ×”), it means the threshold is already defined.
    • Created
      • Shows the timestamp indicating when the rule was originally saved or added to the system.
    • Actions Menu (Three Dots)
      • On each row’s far right, clicking the three dots typically offers additional options, such as edit.

How “Level Score” Works with “Rule Weight”​

  • Rule Weight is assigned to each rule to reflect its relative impact or risk.
  • Level Score is a threshold (for the corresponding Level—e.g., Merchant or Acquirer).
  • If a transaction triggers multiple rules, their weights will be summed. Once the sum reaches (or exceeds) the Level Score, the system will apply a specific action (such as blocking the transaction or sending an escalated alert).

Anti-Fraud Rule Creation Instruction

1. Rule Identification​

1.1 Rule Name
Give the rule a clear, concise name that describes its purpose (e.g., “High-Value Transaction Alert” or “Excessive Declines for Single BIN”).

1.2 Description (Optional)
Optionally include a description to clarify the rule’s intent (e.g., “Alert if transaction amount exceeds a typical threshold”). This helps you and others distinguish rules in the user interface.

2. Selecting the Rule Scope (“Level Type”)​

You must specify at which level the rule will operate:

  1. Merchant – The rule applies only to transactions for a specific merchant.
  2. Acquirer – The rule applies to all merchants that belong to a specific acquirer.
  3. System – The rule applies globally to all transactions in the system.

If a rule is set at the merchant level, it only affects that merchant’s transactions. The same rule at the system level applies to all merchants.

3. Building Rule Conditions​

A rule can contain one or more conditions.

  • All conditions within a single rule are combined by default with a logical AND. That is, every conditions must be satisfied for that rule to trigger.

Conditions can be of three types:

  1. Simple – Checks a single field of the current transaction (e.g., amount, BIN, PAN, country by IP, country of issuer, etc.).
  2. Complex – Selects and analyzes a set of historical transactions in transactions database (e.g., “Has the same PAN had more than 5 declined transactions in the last 24 hours?”).
  3. Operation – Performs mathematical calculations (e.g., sum) on variables captured in a Complex conditions.

In many practical scenarios, your rule might contain:

  • One or more Simple conditions (checking the current transaction’s fields).
  • Followed by a Complex conditions (to look up past transactions), which can define variables for further analysis.
  • Possibly one or more Operation conditions to aggregate those variables (e.g., sum them).
  • A final Simple conditions to compare the aggregated result to a threshold.

3.1 Simple condition​

A Simple condition checks one field of the incoming transaction against a specific value or range. Example fields:

  • amount (transaction amount)
  • currency
  • BIN (Bank Identification Number)
  • PAN (Primary Account Number)
  • status (e.g., success, declined)
  • country by IP (the country inferred from the payer’s IP)
  • country of issuer (the country of the issuing bank)
  • merchantId (the merchant identifier)
  • email (customer’s email address).

Supported comparison operators include (each field has its own individual set of operators):

  • = (equal)
  • > (greater than)
  • < (less than)
  • >= (greater than or equal)
  • <= (less than or equal)

Examples

  • Trigger if transaction amount > 3,000.
  • Decline if country by IP ≠ card issuer’s country (mismatch).
  • Alert if country by IP is in a certain “blacklist” of high-risk countries.

You can have multiple Simple conditions in one rule. For example:

  1. amount > 500
  2. amount <= 1,000

All must match (logical AND) for the rule to trigger.

3.2 Complex conditions​

A Complex condition selects a set of historical transactions that share certain characteristics (e.g., same PAN, same BIN, same merchant, same status, etc.) within a specified time window. Once selected, you can check how many such transactions exist (count), or gather their amounts to aggregate them later.

Within a Complex condition, you typically define:

  • One or more conditions (each is a “binary” check on fields like bin, pan, status, etc.). These conditions are combined by AND for the historical data.
  • A time-based condition if you only want to look within a specific window (e.g., last 24 hours). This is typically done via parameters like duration and measurement (hour, day, etc.).

When multiple conditions are listed under one Complex condition (e.g., count > 5, status = declined), all of them must be satisfied by the historical transactions in order for those transactions to be included in the final set. Then, the condition checks whether that set meets your threshold (e.g., “Is the count > 5?”).

Examples

  • If there are more than 5 declined transactions for the same PAN in the last 24 hours, then do something (Decline, Alert, etc.).
  • If the sum of amounts for all successful transactions with the same BIN is greater than 10,000 in the past 3 days, then do something.

3.2.1 Existence vs. count​

Within a Complex condition, “count” refers to how many historical transactions match the specified conditions (same BIN, same status, etc.). If you say count > 5, it means “At least 6 such historical transactions exist.”

3.2.2 Time-based Checks​

To limit how far back you look, specify a timeframe such as 24 hours or 3 days. Only transactions that occurred in that time window (relative to the current transaction) are counted or aggregated.
For example:

  • If count > 5 AND pan = currentPan AND status = declined AND time < 24 hours, then trigger.

3.3 Operation condition​

An Operation condition lets you aggregate or perform math on the results of a Complex condition. Common operations include:

  • sum

The workflow typically goes like this:

  1. Complex condition finds the relevant historical transactions and can declare a variable to capture a field (for instance, each transaction’s amount) in an array-like structure.
  2. Operation condition sums or otherwise aggregates that array of amounts, storing the result in a new variable (e.g., Sum_Of_Declined_Amounts).
  3. You create a final Simple condition that compares Sum_Of_Declined_Amounts to a threshold (e.g., “> 10,000”).

Example

  1. Complex condition: “Find all declined transactions for the same PAN within the last 24 hours, and store their amount as Declined_Amounts.”
  2. Operation condition: “sum the Declined_Amounts and save as Total_Declined_Amount.”
  3. Simple condition: “If Total_Declined_Amount > 10,000 AND the current transaction amount > 3,000, Decline.”

This approach allows you to implement advanced logic based on historical aggregates.

4. Action Selection​

When all condition of a rule are satisfied, choose an action for the current transaction:

  1. Decline + Alert – Reject the transaction and also send an alert/notification to the anti-fraud officer (via email).
  2. Alert – Approve the transaction but send an alert to the anti-fraud officer (via email).
  3. 3DS – Force a 3D Secure authentication challenge.
  4. Decline – Reject the transaction without sending an alert.

Important:

  • “Alert” by itself does not block the transaction; it merely notifies the relevant party.
  • If no rules apply (or if the final logic deems it safe), the system typically returns an “approve” response. There is no explicit “approve” action in the rule set; approval is the default if no triggered rule stops it.

5. Setting Rule Weight​

Each rule has a weight, indicating how severe or risky the condition is:

  • Higher weight = higher severity or priority.
  • For example, a critical rule might have weight 90, while a minor warning rule might have weight 50.

The weight concept is useful when combined with an overall “score” threshold. If your system is configured to sum the weights of all triggered rules, you can define a “minimum score” that must be reached before a transaction is blocked or flagged. For instance:

  • The system-level (or acquirer-level, or merchant-level) might have a score threshold of 100.
  • If a single rule has weight 60, and the transaction only triggers that one rule, the total is 60, which is less than the threshold of 100 → so the transaction might still pass (unless the rule’s direct action is to Decline).
  • But if the transaction triggers two different 60-weight rules, the combined total is 120, which exceeds the threshold. The system can then decide to block or take some other action.

Implementation Detail:

  • How exactly “score” and “weight” interact can vary. In some setups, the “score threshold” might only apply to certain rules or certain levels.
  • If multiple rules have different actions (e.g., one says Alert, another says Decline), your system should decide which action takes precedence—often the strongest action among triggered rules or the highest-weight rule.

6. Finalizing and Saving the Rule​

After you configure all conditions, choose the desired action and weight. Then:

  1. Click Create Rule to store the rule.
  2. Click Cancel to discard changes.

Your new rule will appear in the rules list, and the system will evaluate every incoming transaction against its conditions.

7. Example Anti-Fraud Configurations​

Below is an examples of configuring an anti-fraud rule.

Example #1: Single Condition → Alert​

This rule simply checks whether the transaction amount is greater than 500. If it is, the system sends an alert to the fraud team. Essentially, it flags larger transactions for further review without automatically declining them, allowing fraud analysts to investigate suspicious activity more closely.

  1. Rule Name
    • In the “Rule name” field, the user enters “Test rule #1.”
  2. Level Type
    • The user chooses “Merchant” as the level type.
    • Then selects the specific merchant (in the screenshot, it’s “John Doe Shop”).
  3. Creating a Conditions
    • The user clicks “Add simple condition.”
    • They set “Amount” as the parameter, select the “>” operator, and enter the value 500.
    • This means: “If the transaction amount is greater than 500...”
  4. Selecting the Action
    • Under “Select an action,” the user chooses “alert.”
    • The weight is set to 100 in this example (you can assign a different weight depending on how critical you consider this rule).
  5. Final Outcome
    • Whenever a new transaction arrives at “John Doe Shop” with an amount greater than 500, the system triggers an alert.
    • The transaction itself is not automatically declined; it simply notifies the anti-fraud team so they can investigate if needed.
  6. Saving the Rule
    • Clicking “Create rule” finalizes and saves this configuration.
    • Afterward, the rule goes into effect, monitoring all future transactions for that merchant.

Example #2: Two Conditions on the Same Parameter → Alert​

This rule checks whether the transaction amount is greater than 500 and less than or equal to 1000. If both conditions are met, the system sends an alert to the fraud team.

  1. Rule Name
    • The user names it “Test rule #2.”
  2. Level Type
    • The user selects “Merchant” as the level type.
    • Chooses “John Doe Shop” as the target merchant.
  3. Creating a Conditions
    • Under “Add simple condition,” the first condition is “Amount > 500.”
    • Another simple condition is added: “Amount <= 1000.”
    • The rule now requires both conditions to be true before it triggers (logical AND).
  4. Selecting the Action
    • Under “Select an action,” the user chooses “alert.”
    • The weight is set to 100 (adjustable based on how critical this range is).
  5. Final Outcome
    • Whenever a transaction at “John Doe Shop” has an amount > 500 and ≤ 1000, the system triggers an alert.
    • Similar to Example #1, the transaction itself is not declined—it is approved unless another rule rejects it, but an alert notifies the fraud team.
  6. Saving the Rule
    • Clicking “Create rule” saves and activates it.
    • From this point on, transactions for that merchant falling into the 501–1000 range will raise an alert for further inspection.

Example #3: Historical Lookup on BIN → Alert​

This rule demonstrates a Complex condition that looks up historical transactions for the same BIN (Bank Identification Number). If there are more than three such transactions, the system will trigger an alert.

  1. Rule Name
    • The user inputs “Test rule #3.”
  2. Level Type
    • The user selects “Merchant” and chooses “John Doe Shop.”
    • This rule applies specifically to that merchant’s transactions.
  3. Creating a Complex Conditions
    • The user configures a “Count” parameter with the operator “>” and sets the value to 3 (meaning we look for more than 3 matching transactions in the history).
    • They also specify “BIN = Current BIN,” indicating the system should filter historical transactions by the same BIN as the current transaction.
    • Both conditions belong to the same complex condition, meaning they must be met simultaneously to trigger the rule.
  4. Selecting the Action
    • Under “Select an action,” the user picks “alert.”
    • The weight is 100 in this example (you can adjust based on severity).
  5. Final Outcome
    • If, for the current transaction’s BIN, the system finds over three historical transactions, it sends an alert.
    • The transaction itself is not automatically blocked, giving the fraud team a chance to review the pattern of repeated BIN usage.
  6. Saving the Rule
    • Clicking “Create rule” activates this logic.
    • From this point on, whenever a BIN has been used more than three times, the fraud team is notified.

Example #4: Time-Based Complex Condition → Alert​

This rule looks for more than three declined transactions with the same BIN as the current transaction within the last 24 hours. If that condition is met, the system issues an alert.

  1. Rule Name
    • The user enters “Test rule #4.”
  2. Level Type
    • The user selects “Merchant” as the level type.
    • Chooses “John Doe Shop” as the specific merchant.
  3. Creating a Complex Conditions
    • Count > 3 specifies that the rule fires if more than three matching transactions are found.
    • BIN = Current BIN instructs the system to filter historical transactions by the same BIN as the current one.
    • Status = declined ensures only declined transactions are considered.
    • Time = last 24 hours (duration = 24, measurement = hour) limits the lookback window to the previous 24 hours.
    • All these parameters are combined into one complex condition; each must be satisfied for the rule to trigger.
  4. Selecting the Action
    • Under “Select an action,” the user chooses “alert.”
    • The weight is set to 100 here but can be adjusted if desired.
  5. Final Outcome
    • If there are more than three declined transactions with the same BIN in the last 24 hours, the system alerts the fraud team.
    • The transaction is still processed unless other rules decline it, ensuring the fraud team can investigate.
  6. Saving the Rule
    • Finally, the user clicks “Create rule.”
    • From that moment on, the rule continuously monitors for repeated declines with the same BIN within the specified time window.

Example #5: Combining a Simple Condition and a Complex Condition → Alert​

This rule uses both a Simple condition and a Complex condition. It first checks if the transaction amount is greater than 1000. Then it looks up how many historical transactions share the same BIN as the current one. If more than three such transactions exist, the system triggers an alert.

  1. Rule Name

    • The user labels it “Test rule #5.”

  2. Level Type

    • The user picks “Merchant” as the level type.
    • Then selects “John Doe Shop.”

  3. Creating Conditions

    1. Simple Condition
      • “Amount > 1000” ensures that only high-value transactions are considered.
    2. Complex Condition
      • “Count > 3” checks if there are more than three previous transactions in the history.
      • “BIN = Current BIN” matches those transactions specifically by the same BIN as the current one.

    Both the simple and complex conditions must be satisfied (logical AND) for the rule to fire.

  4. Selecting the Action

    • The user chooses “alert.”
    • The weight is set to 100 (you can adjust as appropriate).

  5. Final Outcome

    • When the transaction’s amount exceeds 1000 and more than three historical transactions share the same BIN, the system alerts the fraud team.
    • The transaction will proceed unless another rule explicitly declines it, giving the fraud team a chance to review.

  6. Saving the Rule

    • Clicking “Create rule” completes the setup.
    • From then on, big-ticket transactions associated with a BIN that already has multiple past transactions will be flagged for further investigation.

Example #6: Combining a Simple Condition with a Time-Based Complex Condition → Alert​

This rule checks two things:

  1. The current transaction’s amount must be greater than 1000.
  2. There are more than three declined historical transactions with the same BIN in the last 24 hours.

If both conditions are met, the system sends an alert.

  1. Rule Name
    • The user labels it “Test rule #4” in the screenshot (though the exact name can vary).
  2. Level Type
    • The user chooses “Merchant” as the level type.
    • They select “John Doe Shop” to apply the rule to that specific merchant.
  3. Creating Conditions
    • Simple Condition:
      • “Amount > 1000” filters out lower-value transactions.
    • Complex Condition (Historical Lookup):
      • “Count > 3” looks for more than three past transactions.
      • “BIN = Current BIN” ensures we only match transactions that share the same BIN as the current one.
      • “Status = declined” means only previously declined transactions are considered.
      • “Time = last 24 hours” restricts the search to the most recent day.
    • All of these conditions must be satisfied together (logical AND) for the rule to trigger.
  4. Selecting the Action
    • The user chooses “alert” in the action dropdown.
    • They set the weight to 100 (you can adjust this as needed for risk scoring).
  5. Final Outcome
    • Whenever a new transaction with amount > 1000 is processed, the system checks if the same BIN had over three declined transactions in the previous 24 hours.
    • If yes, it alerts the fraud team. The transaction is not automatically declined, giving analysts a chance to investigate.
  6. Saving the Rule
    • Finally, clicking “Create rule” saves and activates it.
    • From that moment on, high-value transactions on a BIN with repeated declines in the last day will be flagged for review.

Example #7: Summing Past Successful Transactions → Alert​

In this scenario, the rule selects all successful transactions from the past 24 hours that share the same PAN (Primary Account Number) as the current transaction, sums their amounts, and alerts if that total exceeds 500. This helps detect repeated or ongoing usage of the same PAN that accumulates to a significant total.

  1. Rule Name
    • The user names it “Test rule #7.”
  2. Level Type
    • The user selects “Merchant”.
    • Chooses “John Doe Shop” from the dropdown.
  3. Creating a Complex Conditions + Variables
    • Condition: PAN = Current PAN
    • Condition: Status = success
    • Time: last 24 hours (duration = 24, measurement = hour)
    • Get Variables:
      • Store each matching transaction’s Amount into a variable named Success_Amount.
    • Operation:
      • sum the Success_Amount array and save the result as Sum_Success_Amount.
    • Simple Check:
      • If Sum_Success_Amount > 500, the rule triggers.
  4. Selecting the Action
    • The user chooses “alert”.
    • The weight is set to 100 here, but can be adjusted if a different scoring is preferred.
  5. Final Outcome
    • If the total amount of successful transactions in the last 24 hours (under the same PAN) exceeds 500, the system alerts the fraud team.
    • The transaction proceeds, but the team is notified of a potentially suspicious accumulation of successful payments.
  6. Saving the Rule
    • The user clicks “Create rule.”
    • The rule activates, continuously checking whether repeated successful transactions exceed the specified threshold.