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.
2. "New Rule" Button - Located at the top-right. Clicking this opens a form to create a new anti-fraud rule.
3. Rules Table - The main area displays a table of all configured rules. Each row corresponds to one rule. The columns include:
   • ID - A unique identifier for the rule.
   • Name - The label given to the rule.
   • Level Type - Indicates the scope of the rule:
     • System - The rule applies globally to all transactions in the system.
     • Acquirer - The rule applies to all merchants under that acquirer.
     • Merchant - The rule affects only a specific merchant's transactions.
     • Shop - The rule applies to a specific shop within a merchant.
     • Payment method - The rule applies to transactions using a specific payment method.
   • Level Name - Shows which specific merchant, acquirer, shop, or payment method this rule is tied to. E.g., if Level Type is "Acquirer" and Level Name is "AeterEdge," it means the rule applies to all merchants under the "AeterEdge" acquirer. For System level rules, this field is not applicable.
   • Status - Indicates whether the rule is currently Active or Disabled. "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. There is no explicit "approve" action. Approval is the default when no triggered rules block the transaction. Available actions:
     • decline - Reject the transaction without notification
     • decline + alert - Reject the transaction and notify the fraud team via email
     • alert - Approve the transaction but notify the fraud team via email
     • 3ds - Force a 3D Secure authentication challenge
     • review - Pause the transaction for manual review with configurable timeout
   • Created - Shows the timestamp indicating when the rule was originally created.
   • Actions Menu (Three Dots) - On each row's far right, clicking the three dots offers additional options such as edit.

---

Anti-Fraud Rule Creation Instructions

System Overview and Processing Flow

The anti-fraud system operates as a pre-processing checkpoint. Anti-fraud decisions are made in real-time before payment processing, ensuring fraudulent transactions are blocked before any financial impact occurs. When a transaction is submitted:

1. Pre-Processing Check: The transaction is evaluated against all applicable anti-fraud rules BEFORE being sent to the payment provider
2. Rule Evaluation: All relevant rules are applied based on the Level Type
3. Decision Making: If multiple rules trigger with different actions, the system applies the strongest action based on priority hierarchy (decline + alert, decline, review, 3ds, alert)
4. Processing Continuation: Only approved transactions proceed to the payment provider. Transactions with review status are paused and await manual decision. Transactions with alert or 3ds statuses proceed after applying respective measures

Rule Identification

Rule Name - Give the rule a clear, concise name that describes its purpose.

Description (Optional) - Include a description to clarify the rule's intent.

Selecting the Rule Scope ("Level Type")

You must specify at which level the rule will operate. This is crucial for both Simple and Complex conditions, but especially critical for Complex conditions as it determines the scope of historical data searches.

1. System

   • The rule applies globally to all transactions in the system
   • For Complex conditions: historical data search includes all transactions across the entire system
   • Use when: Creating global fraud patterns or system-wide thresholds
   • Example: Global decline rate monitoring across all system

2. Acquirer

   • The rule applies to all merchants that belong to a specific acquirer
   • For Complex conditions: historical data search includes all transactions from all merchants under this acquirer
   • Use when: Monitoring patterns specific to an acquirer's merchant portfolio
   • Example: BIN-specific decline patterns affecting multiple merchants under one acquirer

3. Merchant

   • The rule applies only to transactions for a specific merchant
   • For Complex conditions: historical data search is limited to transactions from this merchant only
   • Use when: Creating merchant-specific fraud detection rules
   • Example: Merchant with unique business model requiring custom thresholds

4. Shop

   • The rule applies to transactions from a specific shop within a merchant
   • For Complex conditions: historical data search is limited to transactions from this specific shop only
   • Use when: Different shops have distinct risk profiles
   • Example: High-risk product category shop requiring stricter controls

5. Payment method

   • The rule applies to transactions using a specific payment method
   • For Complex conditions: historical data search includes transactions using this payment method within the defined scope
   • Use when: Specific payment methods show unique fraud patterns
   • Example: Bank transfer fraud patterns differ from card payments

Level Type affects Complex conditions. A rule checking for "5 failed transactions with the same card" will search different datasets:

• System level: Searches across ALL transactions in the entire platform
• Acquirer level: Searches only within that acquirer's merchant transactions
• Merchant level: Searches only within that specific merchant's history
• Shop level: Searches only within that specific shop's transaction history
• Payment method level: Searches transactions using that payment method within the applicable scope

Building Rule Conditions

A rule can contain one or more conditions. All conditions within a single rule are combined with a logical AND operator—every condition must be satisfied for the rule to trigger.

Conditions are of two types:

1. Simple — Checks a single field of the current transaction
2. Complex — Queries historical transaction data based on specified criteria

Simple Conditions

A Simple condition checks one field of the incoming transaction against a specific value, range, or another field.

Available fields include:

• amount - Transaction amount
• currency - Transaction currency
• BIN - Bank Identification Number
• card brand - Payment network (visa, mastercard, amex, etc.)
• issue country - Country of the card-issuing bank
• country by IP - Country inferred from the payer's IP address
• billing country - Country specified in the billing address

Amount-Based Conditions:

When creating Simple conditions that check transaction amounts, it is strongly recommended to also specify the currency field. Without currency specification, the rule may not behave as expected in multi-currency environments.

Example:

• Recommended: Amount > 500 AND Currency = USD
• Not recommended: Amount > 500 (without currency specification)

Complex Conditions

Complex conditions query historical transaction data to identify patterns or anomalies. They select transactions sharing certain characteristics within a specified time window.

Required Parameters for Complex Conditions

IMPORTANT: Complex conditions require different parameters depending on the aggregation type:

• Time window - Required to limit the search scope
• Transaction type - Strongly recommended to specify what you're counting (payment, payout, refund)
• Status - Required for Count and Sum aggregations.

Available aggregation types and parameters:

Aggregation Types:

• Count - Number of matching transactions
• Sum amounts - Total amount of matching transactions
• Decline rate - Percentage of declined transactions
• Has refund - Check if transactions have associated refunds

Filter Parameters:

• BIN - Match transactions with current or specific BIN. Supports exact match and "like" search (partial match from the beginning). When using the "is" operator, additional modifiers become available:
  • Single - Match transactions using the same BIN. Example: "More than 5 transactions from the same BIN in the last hour"
  • Unique - Count unique BINs (for detecting multiple different card issuers). Example: "Transactions from 3+ different BINs indicating card testing"
• PAN - Match transactions with current or specific card number. When using the "is" operator, additional modifiers become available:
  • Single - Match transactions using the same card number. Example: "More than 10 transactions from the same card from this IP"
  • Unique - Count unique card numbers (for detecting multiple different cards from the same source). Example: "More than 10 different cards used from this IP in one hour"
• MID - Match transactions with current MID. When using the "is" operator, additional modifiers become available:
  • Single - Match transactions from the same merchant. Example: "Repeated transactions from the same merchant"
  • Unique - Count unique merchants (for cross-merchant pattern detection). Example: "Transactions spanning across 5+ different merchants"
• Email - Match transactions with current email
• Customer - Match transactions from current customer
• IP address - Match transactions from current IP
• Device fingerprint - Match transactions with current device fingerprint
• Status - Filter by transaction status. Cannot be used with decline rate
  • success - Completed transactions
  • failed - Declined or failed transactions
  • override - Transactions modified during two-stage processing (see detailed explanation below)
• Country by IP - Match transactions from specific IP-based countries
• Currency - Match transactions in specific currency
• Payment settings - Match transactions with specific payment configuration
• Status code - Filter by specific error codes. When using the "is" operator, additional modifiers become available:
  • Single - Detects when multiple transactions share the same status code, regardless of which specific code it is. The system groups transactions by their status code and triggers if any group meets the count threshold.
    • Example: "Count > 3 and Status code is single" will trigger if:
      • 4 transactions with code 4051 (insufficient funds), OR
      • 4 transactions with code 4055 (transaction declined), OR
      • 4 transactions with ANY other single code
• Time - Define the time window for historical data search
• Transaction type - Payment, Payout, Refund

Transaction Type Filtering

All rules can be filtered by transaction type to focus on specific payment flows:

Available Transaction Types:

• payment - Standard payment transactions from customers
• payout - Outbound payments to recipients (withdrawals, transfers)
• refund - Refund transactions reversing previous payments

Usage Guidelines:

• Use payment filtering for customer fraud detection rules
• Use payout filtering for detecting unusual withdrawal patterns
• Use refund filtering for monitoring refund abuse or processing errors
• Combine with other conditions to create transaction-type-specific rules

Example: Monitor excessive refund requests by filtering for transaction_type = refund combined with PAN and time window conditions.

"Override" Status

The "override" status applies to transactions in two-stage processing scenarios with capture functionality:

1. Initial Transaction: Customer requests a transaction for a specific amount
2. Pre-Capture Stage: Transaction is authorized but not yet captured/sent to the payment provider
3. Amount Modification: Instead of confirming the original amount, the merchant sends a capture request with a different (usually increased) amount
4. Override Creation: The system marks the original transaction as "override" and creates a new transaction with the updated amount

Use Cases for Override in Anti-Fraud Rules:

• Detect merchants frequently increasing transaction amounts before capture
• Monitor patterns of amount manipulation that could indicate fraudulent behavior
• Track unusual capture behavior across different merchants or time periods

Example: A merchant consistently authorizes transactions for $100 but captures them for $150.

Decline Rate

Decline rate is the ratio of failed transactions to total transactions for specified criteria over a time period.

Formula: (Failed Transactions / Total Transactions) × 100

Advanced Status Code Usage

Beyond basic fraud detection, status codes enable sophisticated pattern analysis:

Common Status Code Applications:

• 4051 (Insufficient Funds): Detect repeated payment attempts or card testing
• 4052 (Invalid Card): Identify systematic card validation attacks
• 4053 (Expired Card): Monitor outdated card usage patterns
• 4054 (Wrong CVV): Flag potential fraud attempts
• 4055 (Transaction Declined): Generic decline pattern analysis
• 4056 (Card Restricted): Detect restricted card usage attempts

Has Refund Conditions

The Has Refund condition detects refund-related fraud patterns by analyzing the timing and frequency of refunds relative to original payments.

Has Refund Parameters:

• Time Window: Specify how quickly refunds must occur after original payment
• Duration: Set the time measurement (hours, days, weeks)
• Transaction Matching: Automatically links refunds to their corresponding payments

Common Use Cases:

• Refund Fraud Detection: Identify payments that are quickly refunded, indicating potential fraud
• Processing Issues: Monitor technical problems causing immediate refunds
• Chargeback Prevention: Detect patterns that might lead to chargebacks

Configuration Example:

has_refund:
  duration < 10
  measurement = day

This detects payments that have associated refunds within 10 days.

Variables and Comparisons

Variables allow you to:

1. Store results from Complex conditions
2. Compare multiple Complex condition results

Variable Types:

• Sum of amounts - Store pre-summed transaction amounts from Sum amounts aggregation
• Count - Store count values from Count aggregation
• Pan - Store arrays of PAN values from complex conditions for later use

Variable Usage:

• Complex conditions can store their count or sum results in named variables
• Variables can be compared using Simple conditions
• Coefficients can be applied only to count variables for proportional comparisons

Coefficient-Based Comparisons: Coefficients enable sophisticated proportional analysis and are only available for count variables:

• Compare count variables with multipliers
• Example: fail_count > 0.5 × success_count (failures exceed half of successes)
• Useful for percentage-based rules without explicit percentage calculations

Action Selection and Rule Conflicts

Choose the action when all rule conditions are satisfied:

1. Decline + Alert — Reject the transaction and send email notification to the anti-fraud team
2. Decline — Reject the transaction without notification
3. Review — Pause the transaction for manual review within a configurable timeout period. The merchant must make a decision (accept or decline) via API, otherwise the transaction is automatically declined after the timeout expires. Learn more about manual review
4. 3DS — Force 3D Secure authentication challenge
5. Alert — Approve the transaction but send email notification for review

Multiple Rule Conflicts

When multiple rules trigger for the same transaction, the system applies action hierarchy:

Action Priority (Strongest to Weakest):

1. Decline + Alert (Highest priority)
2. Decline
3. Review
4. 3DS
5. Alert (Lowest priority)

Conflict Resolution Examples:

• Rule A triggers "Alert" + Rule B triggers "Decline" = Transaction is Declined
• Rule A triggers "3DS" + Rule B triggers "Decline + Alert" = Transaction is Declined with Alert
• Multiple "Alert" rules = Single alert notification sent with all rule IDs

Email Alert

Alert Notifications

The anti-fraud system automatically sends email notifications when rules with "Alert" or "Decline + Alert" actions trigger.

Alert Email Contents:

• Transaction ID and basic details
• Triggered rule name and ID
• Rule conditions that matched
• Direct links to transaction details in admin panel

Finalizing and Saving the Rule

After configuring all conditions and action:

1. Review all conditions for completeness
2. Click Create Rule to save and activate
3. Click Cancel to discard changes

The new rule appears in the rules list and immediately begins evaluating incoming transactions.

---

Status Code Reference

Code	Description	Common Use Case
4000	Approved	Monitor successful transaction patterns
4001	Refer To Issuer	Detect cards requiring manual verification
4002	Refer To Issuer Condition	Track conditional approval patterns
4003	Invalid Merchant	Identify merchant configuration issues
4004	Capture Card	Flag potentially compromised cards
4005	Do Not Honor	Monitor general issuer declines
4006	Error	Track processing errors
4007	Pickup Card Fraud	Detect fraud account patterns
4008	Honor Id	Monitor ID verification requirements
4010	Partial Approval	Track partial payment patterns
4011	Approved VIP	Monitor VIP transaction patterns
4012	Invalid Transaction	Detect malformed transaction attempts
4013	Invalid Amount	Flag unusual amount patterns
4014	Invalid Card Number	Identify card number testing
4015	Invalid Issuer	Track issuer-related problems
4016	Approved Update Track3	Monitor track data update patterns
4017	Decline Customer Cancel	Track customer cancellation patterns
4019	Re-enter Transaction	Detect retry patterns
4020	Update QRC	Monitor QR code update requirements
4021	Card Not Init	Track uninitialized card usage
4022	Suspect Malfunction	Detect system malfunction patterns
4025	Original Tx Not Found	Monitor refund/void attempt patterns
4028	File Temp Unavailable	Track temporary system issues
4030	Format Error	Detect data format attack patterns
4032	Decline Partial Reversal	Monitor partial reversal patterns
4033	Expired Card Pickup	Track expired card usage patterns
4034	Fraud	Direct fraud detection indicator
4038	Pin Limit Exceeded	Detect PIN brute force attempts
4039	No Credit Account	Track credit account availability
4040	Unsupported Function	Monitor unsupported operation attempts
4041	Lost Card	Flag lost card usage patterns
4043	Stolen Card	Detect stolen card usage
4045	Fallback Not Allowed	Track fallback transaction patterns
4051	Insufficient Funds	Detect repeated payment attempts
4052	No Cheque Account	Monitor cheque account issues
4053	No Savings Account	Track savings account problems
4054	Expired Card	Pattern analysis for expired cards
4055	Invalid PIN	Fraud indicator for PIN attacks
4057	Not Permitted Issuer	Track issuer restriction patterns
4058	Not Permitted Acquirer	Monitor acquirer restriction patterns
4059	Suspected Fraud	Direct fraud suspicion indicator
4061	Exceeds Withdrawal Amt	Monitor withdrawal limit violations
4062	Restricted Card	Restricted card usage patterns
4063	Security Violation	Track security breach attempts
4064	Original Tx Amount Err	Monitor transaction amount discrepancies
4065	Exceeds Withdrawal Count	Track withdrawal frequency violations
4068	Response Late	Monitor timeout patterns
406P	Verification Fail	Track verification data failures
4070	Contact Issuer	Monitor issuer contact requirements
4071	Pin Not Changed	Track PIN change failures
4074	Pin Encryption Error	Detect PIN encryption issues
4075	Pin Tries Exceeded	Monitor PIN attempt limit violations
4076	Invalid To Account	Track account transfer errors
4077	Invalid From Account	Monitor source account issues
4078	Invalid Account	General account validation failures
4079	Lifecycle MC	Track Mastercard lifecycle issues
4080	Visa Credit Issuer Unavailable	Monitor Visa issuer availability
4081	Domestic Debit Not Allowed	Track domestic debit restrictions
4082	Policy MC	Monitor Mastercard policy violations
4083	Fraud Security MC	Detect Mastercard fraud indicators
4084	Invalid Auth Lifecycle	Track authorization lifecycle issues
4085	Not Declined	Monitor non-decline patterns
4086	Pin Val Impossible	Track PIN validation failures
4087	Purchase No Cashback	Monitor cashback restriction patterns
4088	Crypto Fail	Detect cryptographic failures
4089	Pin Unacceptable	Track unacceptable PIN patterns
4090	Cutoff In Process	Monitor cutoff period transactions
4091	Auth Sys Inoperative	Track authorization system outages
4092	Unable To Route	Monitor routing failure patterns
4093	Tx Violation Of Law	Detect legal violation attempts
4094	Duplicate Transmission	Track duplicate transaction patterns
4096	System Error	Monitor general system errors
4097	Atm Pos Term Not Found	Track terminal identification issues
4098	Issuer Resp Not Received	Monitor issuer response timeouts
4099	Pin Block Error	Detect PIN block format errors
40A0	Mac Failed	Track MAC validation failures
40A2	Success Fault	Monitor successful transactions with faults
40A3	Account Not Found Transfer	Track transfer account issues
40A7	Security Proc Fail	Detect security processing failures
40B1	No Arrears Receipt	Monitor receipt processing issues
40C1	Illegal Acquirer Status	Track acquirer status violations
40D1	Incorrect IIN	Monitor incorrect IIN patterns
40D2	Date Error	Track date-related processing errors
40D3	Invalid File Type	Monitor file processing issues
40D4	File Processed	Track file processing status
40D5	No Such File	Monitor file availability issues
40D6	Not Supported Receiver	Track receiver compatibility issues
40D7	File Locked	Monitor file locking patterns
40D8	Unsuccessful	Track general processing failures
40D9	Incorrect File Length	Monitor file format issues
40DA	File Compression Error	Track compression failure patterns
40DB	File Name Error	Monitor file naming issues
40DC	File Cannot Be Received	Track file reception failures
40F1	File Record Format Error	Monitor record format issues
40F2	File Record Repeat	Track duplicate record patterns
40F3	File Record Not Exist	Monitor missing record issues
40F4	File Record Error	Track general record errors
400A	Approval Load	Monitor approval with load patterns
401A	Sca Required Visa	Track SCA requirement patterns
40N0	Force Stip	Monitor STIP enforcement patterns
40N1	Items Not On Bankbook	Track bankbook limit violations
40N3	Cash Not Available	Monitor cash service availability
40N4	Cashback Exceeds Limit	Track cashback limit violations
40N7	Decline Cvv2	Detect CVV2 validation failures
40N8	Tx Amt Exceeds Pre Auth	Monitor pre-authorization violations
40P1	Contact Number Not Found	Track contact information issues
40P2	Invalid Billing	Monitor billing validation failures
40P5	Pin Change Declined	Track PIN change failure patterns
40P6	Unsafe Pin	Detect unsafe PIN patterns
40Q1	Card Auth Failed	Track card authentication failures
40R0	Stop Payment	Monitor stop payment order patterns
40R1	Revoke Auth	Track authorization revocation patterns
40R2	Tx Not Qualify Visa Pin	Monitor Visa PIN qualification issues
40R3	Revoke All Auth	Track mass authorization revocations
40Y1	Offline Tx Success	Monitor offline transaction patterns
40Y3	Offline Tx Success No Online	Track offline-only transaction patterns
40Z1	Offline Tx Fail	Monitor offline transaction failures
40Z3	No Online Declined	Track online connectivity issues
40Z5	Valid Account Amt Not Supported	Monitor amount support limitations
40Z6	Invalid Mcc Use	Track MCC usage violations

Glossary

• BIN: Bank Identification Number - first 6-8 digits of a card
• PAN: Primary Account Number - full card number
• MID: Merchant Identifier - unique merchant code
• Decline Rate: Percentage of failed vs total transactions
• Level Type: Scope of rule application (System/Acquirer/Merchant/Shop/Payment method)
• Complex Condition: Query against historical transaction data
• Simple Condition: Check against current transaction fields
• Has Refund: Specialized condition for detecting refund timing patterns
• Override Status: Transaction modified during two-stage processing with capture
• Status Code: Specific error code from payment processor
• Device Fingerprint: Unique identifier combining browser and device data
• Variables: Named storage for numeric values from Complex conditions
• Coefficients: Multipliers used in count variable comparisons for proportional analysis
• Action Hierarchy: Priority system determining final action when multiple rules trigger
• Transaction Type: Classification of transaction as payment, payout, or refund
• Multi-Currency: System capability to handle multiple currencies with automatic conversion

---

Example Anti-Fraud Configurations

Below are examples of increasingly complex anti-fraud rule configurations.

Simple examples

Example #1: Single Simple Condition → Alert

Scenario: Flag large transactions for review

1. Rule Name: "Test rule #1"
2. Level Type: Merchant
3. Simple Condition:
   • Amount > 500
   • Currency = USD
4. Action: Alert

Result: Transactions over 500 at this merchant trigger email alerts without blocking.

Example #2: Multiple Simple Conditions → Alert

Scenario: Flag mid-range transactions

1. Rule Name: "Test rule #2"
2. Level Type: Merchant
3. Simple Conditions:
   • Amount > 500
   • Amount ≤ 1000
   • Currency = USD
4. Action: Alert

Result: Transactions between 500.01-1000 trigger alerts.

Example #3: Historical BIN Lookup → Alert

Scenario: Detect repeated BIN usage

1. Rule Name: "Test rule #3"
2. Level Type: Merchant
3. Complex Condition:
   • Count > 3
   • BIN = Current BIN
   • Status = success
   • Transaction type = payment
   • Time = 365 days
4. Action: Alert

Result: Alert when a BIN has been used more than 3 times in the past year.

Example #4: Time-Based Complex Condition → Alert

Scenario: Detect velocity attacks

1. Rule Name: "Test rule #4"
2. Level Type: Merchant
3. Complex Condition:
   • Count > 3
   • BIN = Current BIN
   • Status = declined
   • Time = 24 hours
   • Transaction type = payment
4. Action: Alert

Result: Alert when same BIN has >3 declines in 24 hours.

Example #5: Combined Simple and Complex → Alert

Scenario: High-value transactions with suspicious history

1. Rule Name: "Test rule #5"
2. Level Type: Merchant
3. Simple Condition:
   • Amount > 1000
   • Currency = EUR
4. Complex Condition:
   • Count > 3
   • BIN = Current BIN
   • Status = success
   • Transaction type = payment
   • Time = 30 days
5. Action: Alert

Result: Alert for high-value transactions when BIN has extensive history.

Example #6: Multiple Condition Types → Alert

Scenario: High-value transaction after multiple failures

1. Rule Name: "Test rule #6"
2. Level Type: Merchant
3. Simple Condition:
   • Amount > 1000
   • Currency = EUR
4. Complex Condition:
   • Count > 3
   • BIN = Current BIN
   • Transaction type = payment
   • Status = failed
   • Time = 24 hours
5. Action: Alert

Result: Alert for large transactions following recent failures.

Example #7: Sum Operation with Variables → Alert

Scenario: Cumulative spending limit

1. Rule Name: "Test rule #7"
2. Level Type: Merchant
3. Complex Condition:
   • Sum amounts > 500
   • Currency = EUR
   • PAN = Current PAN
   • Status = success
   • Transaction type = payment
   • Time = 24 hours
4. Action: Alert

Result: Alert when total successful transactions for a card exceed 500 in 24 hours.

Advanced examples

Example #8: Decline Rate with Status Code

Scenario: High decline rate for insufficient funds

1. Rule Name: "Insufficient Funds Pattern"
2. Level Type: Acquirer
3. Complex Condition:
   • Decline Rate > 30% and Status Code = "4051" (Insufficient Funds)
   • BIN = Current BIN
   • Time = 24 hours
   • Transaction type = payment
   • Count ≥ 100 (minimum transactions for significance)
   • PAN is unique
4. Action: Decline + Alert

Result: Block transactions when BIN shows pattern of insufficient funds across many unique cards.

Example #10: Geographic Mismatch Detection

Scenario: Detect potential card fraud through geographic inconsistencies

1. Rule Name: "Geographic Fraud Detection"
2. Level Type: System
3. Simple Conditions:
   • Country by IP ≠ Issue country
   • Amount > 1000
   • Currency = EUR
4. Complex Condition:
   • Count > 5
   • PAN = Current PAN
   • Transaction Type = payment
   • Status = failed
   • Time = 6 hours
5. Action: Decline + Alert

Result: Block high-value transactions from different countries when the card has recent failure history.

Example #11: Has Refund Detection

Scenario: Detect rapid refund fraud patterns

1. Rule Name: "Rapid Refund Fraud"
2. Level Type: Merchant
3. Complex Condition:
   • BIN = Current BIN
   • Transaction Type = payment
   • Has Refund: duration < 2 days
4. Simple Condition:
   • Amount > 1000
   • Currency = EUR
5. Action: Decline + Alert

Result: Block high-value payments from BINs that show patterns of quick refunds.

Example #12: Multi-Currency Fraud Detection

Scenario: Detect unusual currency mixing patterns

1. Rule Name: "Currency Switching Pattern"
2. Level Type: System
3. Complex Condition 1:
   • Count > 2
   • PAN = Current PAN
   • Currency = EUR
   • Transaction type = payment
   • Time = 4 hours
4. Complex Condition 2:
   • Count > 2
   • PAN = Current PAN
   • Transaction type = payment
   • Currency = USD
   • Time = 4 hours
5. Action: Alert

Result: Alert when same card attempts transactions in multiple currencies within short timeframe.

Example #13: BIN Decline Rate Pattern Detection

Scenario: Detect BINs with high decline rates for specific error messages across multiple merchants

1. Rule Name: "BIN High Decline Pattern"
2. Level Type: System
3. Complex Condition 1:
   • Decline Rate > 30% and Status Code = [specific error code]
   • BIN = Current BIN
   • PAN is unique
   • Transaction type = payment
   • MID is single
   • Time = 24 hours
4. Complex Condition 2:
   • Count ≥ 3
   • BIN = Current BIN
   • Transaction type = payment
   • MID is unique
   • Time = 48 hours
5. Action: Decline + Alert

Result: Block transactions from BINs showing systematic decline patterns across multiple merchants.

Example #14: High-Value Refund with Chargeback Pattern

Scenario: Block transactions when cumulative refunds exceed threshold with chargeback history

1. Rule Name: "High Refund Risk Pattern"
2. Level Type: Merchant
3. Complex Condition 1:
   • Count ≥ 3
   • PAN = Current PAN
   • Transaction Type = payment
   • Status = success
   • Has Refund: duration < 2 days
   • Time = 30 days
4. Complex Condition 2:
   • Sum amounts > 2500
   • PAN = Current PAN
   • Transaction Type = refund
   • Status = success
   • Time = 7 days
5. Simple Condition:
   • Amount > 1000
   • Currency = USD
6. Action: Decline + Alert

Result: Block high-value transactions from cards with excessive recent refund amounts and history of quick refunds.

Example #15: Refund Exceeds Payment Amount

Scenario: Detect when refunds exceed total payment amounts

1. Rule Name: "Refund Payment Imbalance"
2. Level Type: Merchant
3. Complex Condition 1:
   • Sum amounts → store as "total_refunds"
   • PAN = Current PAN
   • Transaction Type = refund
   • Status = success
   • Time = 24 hours
4. Complex Condition 2:
   • Sum amounts → store as "total_payments"
   • PAN = Current PAN
   • Transaction Type = payment
   • Status = success
   • Time = 24 hours
5. Simple Condition:
   • total_refunds > total_payments
6. Action: Decline + Alert

Result: Block cards where refund amounts exceed payment amounts indicating potential fraud.

Example #16: High-Risk Jurisdiction with Failed Attempts

Scenario: Block cards from high-risk countries with multiple failures

1. Rule Name: "High-Risk Country Pattern"
2. Level Type: System
3. Complex Condition 1:
   • Count > 5
   • PAN = Current PAN
   • Time = 24 hours
   • Transaction type = payment
4. Complex Condition 2:
   • Count ≥ 3
   • PAN = Current PAN
   • Status = failed
   • Time = 24 hours
   • Transaction type = payment
5. Simple Condition:
   • Issue country IN ["AF", "AL", "BA", "BY", "CF", "CG", "CD", "CU", "GN", "GW", "HT", "IR", "IQ", "LB", "LY", "ML", "MM", "NI", "KP", "PK", "SO", "SS", "SD", "SY", "VE", "YE", "ZW"]
6. Action: Decline + Alert

Result: Block cards from high-risk jurisdictions with suspicious failure patterns.

Example #17: MID Insufficient Funds Pattern

Scenario: Monitor merchants with high insufficient funds decline rates

1. Rule Name: "MID Insufficient Funds Monitor"
2. Level Type: Merchant
3. Complex Condition:
   • Decline Rate > 30% and Status Code = "4051" (Insufficient Funds)
   • MID = Current MID
   • Time = 24 hours
   • Transaction type = payment
   • Count ≥ 50
4. Action: Alert

Result: Alert when merchant shows high insufficient funds decline rate.

Example #18: New Customer High-Value Transaction

Scenario: Flag first-time high-value transactions with geographic mismatch

1. Rule Name: "New Customer High Value"
2. Level Type: Merchant
3. Complex Condition 1:
   • Count = 0
   • Customer = Current Customer
   • MID = Current MID
   • Transaction type = payment
4. Complex Condition 2:
   • Count = 0
   • PAN = Current PAN
   • Transaction type = payment
5. Simple Conditions:
   • Amount ≥ 3000
   • Currency = EUR
   • Country by IP ≠ Billing country
   • Transaction type = payment
6. Action: Decline + Alert

Result: Block high-value first-time transactions with geographic inconsistencies.

Example #19: Multiple Cards Same IP with Failures

Scenario: Detect card testing from single IP address

1. Rule Name: "IP Card Testing Pattern"
2. Level Type: System
3. Complex Condition 1:
   • Count > 5
   • IP address = Current IP
   • Status = success
   • PAN is unique store as variable "successful_pans"
   • Time = 24 hours
   • Transaction type = payment
4. Complex Condition 2:
   • Count ≥ 3
   • PAN IN "successful_pans"
   • Status = failed
   • Transaction type = payment
   • Time = 24 hours
5. Action: Decline + Alert

Result: Block IPs showing card testing patterns with multiple cards and failures.

Example #20: Multiple Cards Same Device Fingerprint

Scenario: Detect multiple cards from same device

1. Rule Name: "Device Multiple Cards"
2. Level Type: System
3. Complex Condition:
   • Count > 5
   • IP address = Current IP
   • Status = success
   • PAN is unique
   • Device fingerprint = Current Device fingerprint
   • Transaction type = payment
   • Time = 24 hours
4. Action: Decline + Alert

Result: Block devices using multiple different cards indicating potential fraud.

Example #21: Email Linked to Multiple Cards

Scenario: Detect single contact information used with multiple cards

1. Rule Name: "Contact Info Multiple Cards"
2. Level Type: System
3. Complex Condition 1:
   • Count ≥ 3
   • Email = Current Email
   • Status = success
   • PAN is unique
   • Transaction type = payment
   • Time = 30 days
4. Action: Decline + Alert

Result: Block contact information associated with multiple different cards.

Example #22: Geographic Velocity Check

Scenario: Detect impossible travel patterns

1. Rule Name: "Geographic Velocity Fraud"
2. Level Type: System
3. Complex Condition:
   • Count ≥ 1
   • PAN = Current PAN
   • Country by IP ≠ Current Country by IP
   • Device fingerprint ≠ Current Device fingerprint
   • Time = 15 minutes
   • Transaction type = payment
4. Action: Decline + Alert

Result: Block cards showing impossible geographic velocity patterns.