Rules Menu Overview

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

Search Bar - Located at the top-left, this allows you to filter the list of rules.
"New Rule" Button - Located at the top-right. Clicking this opens a form to create a new anti-fraud rule.
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
- 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:

Pre-Processing Check: The transaction is evaluated against all applicable anti-fraud rules BEFORE being sent to the payment provider
Rule Evaluation: All relevant rules are applied based on the Level Type
Decision Making: If multiple rules trigger with different actions, the system applies the strongest action (decline overrides alert, decline + alert overrides decline)
Processing Continuation: Only approved transactions proceed to the payment provider

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.

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
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
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
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
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 four types:

Simple — Checks a single field of the current transaction
Complex — Queries historical transaction data based on specified criteria
Operation — Performs mathematical calculations on variables from Complex conditions

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
PAN - Primary Account Number (card number)
card_brand - Payment network (visa, mastercard, amex, etc.)
status - Transaction status (success, declined, etc.)
country by IP - Country inferred from the payer's IP address
country of issuer - Country of the card-issuing bank
billing country - Country specified in the billing address
merchantId - Merchant identifier
email - Customer's email address
MID - Merchant ID from payment settings

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.

Complex Conditions

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

Mandatory Parameters for Complex Conditions

CRITICAL: Almost every Complex condition MUST include these three parameters to function properly:

Time window - To limit the search scope

Transaction type - To specify what you're counting

Status

Without these parameters, rules will produce unexpected results and may be functionally meaningless.

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
PAN - Match transactions with current or specific card number
MID - Match transactions with current MID
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
Time - Define the time window for historical data search
Transaction type - Payment, Payout, Refund

"Override" Status

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

Initial Transaction: Customer requests a transaction for a specific amount
Pre-Capture Stage: Transaction is authorized but not yet captured/sent to the payment provider
Amount Modification: Instead of confirming the original amount, the merchant sends a capture request with a different (usually increased) amount
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

Important Decline Rate Rules:

DO NOT specify a status condition when using decline rate (it's calculated automatically)
Status code is OPTIONAL - you can specify it to calculate decline rate for specific error types only
Without status code, all failures are counted in the calculation

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.

Advanced Refund Scenarios:

Rapid Refund Pattern: Payment followed by refund within 24 hours
Partial Refund Analysis: Detect unusual partial refund patterns
Cross-Card Refund Fraud: Monitor refunds to different cards than original payment

Business Context: Legitimate refunds typically occur 3-7 days after purchase, while fraudulent transactions often show refund requests within 24-48 hours.

Operation Conditions

Operation conditions perform mathematical calculations on variables captured from Complex conditions.

Workflow:

Complex condition captures values into a variable (e.g., amounts, counts)
Operation condition performs calculation (e.g., sum)
Simple condition compares the result to a threshold or another variable

Available Operations:

sum - Add all values in the variable array
count - Count specific values (e.g., count of specific status)

Variables and Comparisons

Variables allow you to:

Store results from Complex conditions
Compare multiple Complex condition results

Variable Types:

amount - Store transaction amounts for later summation
count - Store count directly from complex conditions (actual number, not true/false)
status - Store status values for counting specific statuses

Variable Usage:

Complex conditions can store their count or sum results in named variables
These variables contain the actual numeric results (e.g., 15 transactions, $2,500 total)
Variables can be compared using Simple conditions
Coefficients can be applied for proportional comparisons

Coefficient-Based Comparisons: Coefficients enable sophisticated proportional analysis:

Compare variables with multipliers
Example: fail_count > 0.5 × success_count (failures exceed half of successes)
Example: refund_amount > 0.3 × payment_amount (refunds exceed 30% of payments)
Useful for percentage-based rules without explicit percentage calculations

Action Selection and Rule Conflicts

Choose the action when all rule conditions are satisfied:

Decline + Alert — Reject the transaction and send email notification to the anti-fraud team
Decline — Reject the transaction without notification
3DS — Force 3D Secure authentication challenge
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):

Decline + Alert (Highest priority)
Decline
3DS
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:

Review all conditions for completeness
Click Create Rule to save and activate
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 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

Rule Name: "Test rule #1"
Level Type: Merchant
Condition: Simple condition - Amount > 500
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

Rule Name: "Test rule #2"
Level Type: Merchant
Conditions:
- Amount > 500 AND
- Amount ≤ 1000
Action: Alert

Result: Transactions between 501-1000 trigger alerts.

Example #3: Historical BIN Lookup → Alert

Scenario: Detect repeated BIN usage

Rule Name: "Test rule #3"
Level Type: Merchant
Complex Condition:
- Count > 3
- BIN = Current BIN
Action: Alert

Result: Alert when a BIN has been used more than 3 times in history.

Example #4: Time-Based Complex Condition → Alert

Scenario: Detect velocity attacks

Rule Name: "Test rule #4"
Level Type: Merchant
Complex Condition:
- Count > 3
- BIN = Current BIN
- Status = declined
- Time = last 24 hours
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

Rule Name: "Test rule #5"
Level Type: Merchant
Conditions:
- Simple: Amount > 1000
- Complex: Count > 3, BIN = Current BIN
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

Rule Name: "Test rule #6"
Level Type: Merchant
Conditions:
- Simple: Amount > 1000
- Complex: Count > 3, BIN = Current BIN, Status = declined, Time = 24 hours
Action: Alert

Result: Alert for large transactions following recent failures.

Example #7: Sum Operation with Variables → Alert

Scenario: Cumulative spending limit

Rule Name: "Test rule #7"
Level Type: Merchant
Complex Condition:
- PAN = Current PAN
- Status = success
- Time = last 24 hours
- Store amounts in variable: "Success_Amount"
Operation: Sum "Success_Amount" → "Sum_Success_Amount"
Simple Condition: Sum_Success_Amount > 500
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

Rule Name: "Insufficient Funds Pattern"
Level Type: Acquirer
Complex Condition:
- Decline Rate > 30%
- Status Code = "4051" (Insufficient Funds)
- BIN = Current BIN
- Time = last 24 hours
- Count ≥ 100 (minimum transactions for significance)
- PAN is uniq (unique cards)
Action: Decline + Alert

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

Example #9: Variable Comparison with Coefficient

Scenario: Detect disproportionate failures

Rule Name: "Failure Rate Analysis"
Level Type: System
Complex Condition 1:
- Count all transactions → store as "total_count"
- MID = Current MID
- Time = last 24 hours
Complex Condition 2:
- Count failed transactions with status_code "4051" → store as "fail_51_count"
- MID = Current MID
- Time = last 24 hours
Simple Condition: fail_51_count > 0.5 × total_count
Action: Alert

Result: Alert when more than half of transactions fail with insufficient funds.

Example #10: Geographic Mismatch Detection

Scenario: Detect potential card fraud through geographic inconsistencies

Rule Name: "Geographic Fraud Detection"
Level Type: System
Simple Conditions:
- Country by IP ≠ Country of issuer
- Amount > 1000
Complex Condition:
- Count > 5
- PAN = Current PAN
- Status = failed
- Time = last 6 hours
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

Rule Name: "Rapid Refund Fraud"
Level Type: Merchant
Complex Condition:
- BIN = Current BIN
- Transaction Type = payment
- Has Refund: duration < 2 days
Simple Condition: Amount > 1000
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

Rule Name: "Currency Switching Pattern"
Level Type: System
Complex Condition 1:
- Count transactions → store as "eur_count"
- PAN = Current PAN
- Currency = EUR
- Time = last 4 hours
Complex Condition 2:
- Count transactions → store as "usd_count"
- PAN = Current PAN
- Currency = USD
- Time = last 4 hours
Simple Condition: eur_count > 3 AND usd_count > 3
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