--- page_title: Configuration Counters product: Juspay FRM page_source: https://juspay.io/in/docs/juspay-frm/docs/program-management/configuration-counters llms_txt: https://juspay.io/in/docs/llms.txt product_llms_txt: https://juspay.io/in/docs/juspay-frm/llms.txt --- # Configuration Guide In this guide, we’ll cover the following topics: * [Steps to configure a counter.](https://juspay.io/in/docs/juspay-frm/docs/program-management/configuration-counters#Steps-to-create-a-counter:%E2%80%8B) * Demonstration video on creating a counter. * [Pre-Transaction Counters](https://juspay.io/in/docs/juspay-frm/docs/program-management/configuration-counters#1.-Pre-Transaction-Counters) * [Explicit Counters (Post Transaction)](https://juspay.io/in/docs/juspay-frm/docs/program-management/configuration-counters#2.-Configuring-Explicit-Counters) --- ## Steps to create a counter: ![Image](https://dth95m2xtyv8v.cloudfront.net/tesseract/assets/juspay-frm/Steps%20for%20configuring%20counters_%20-%20visual%20selection%20(2)-s8Y6U.png) Now, let’s delve deep into understanding the configuration steps in detail. ### Step 1. Setting up an FRM Program 1. Login to [Juspay Dashboard](https://portal.juspay.in/) 2. Navigate to **FRM Module** » **Program Configuration » Create FRM Program** 3. Enter a descriptive**Program Name** » **Result Type** as **Risk Status** . 4. Define the program**Validity Period** by setting the **start and end date** (including time, if required). ### Step 2. Create a Counter 1. Under Program Dashboard, click **+ Add Counters** 2. Provide a **Counter Name** that clearly describes the counter’s intent * _**Pre-Transaction Counter Example**_ _: Limiting Daily Credit Card Transactions Per Customer._ * _**Explicit Transaction Example:**_ _Temporarily Blocking Transaction after 5 Failed Transactions._ ### Step 3. Decide Counter Evaluation Type ## Pre-Transaction Use [Pre-Transaction](https://juspay.io/in/docs/juspay-frm/docs/program-management/counter-types#1.-Pre-Transaction-Counters) when transactions must be **blocked or flagged immediately** , before the payment gateway is called. ### **Example Configuration** For this example, we will configure a **pre-transaction counter** to **limit daily credit card usage** . **Scenario** A user should be allowed to perform **up to 5 credit card transactions per day** . Any transaction beyond this limit should be rejected before payment processing. **Configuration in this step** * **Evaluation Type:** Pre-Transaction * **Operation:** Number of transactions ## Post-Transaction Use **[Explicit Counters](https://juspay.io/in/docs/juspay-frm/docs/program-management/counter-types#2.-Explicit-Counters-Post-Transaction-Counters)** when enforcement depends on the **transaction outcome** , such as repeated failures. 1. Configure **which transaction outcomes should increment the counter** . #### Supported Triggers: * Authentication Failed, Juspay Declined, Authorization Failed, Failed **Example** If a customer has **2 authentication failures** , Flag/ Reject the **3rd attempt** until the reset period expires. 2. Select one of the**** **[supported operations](https://juspay.io/in/docs/juspay-frm/docs/program-management/counter-types#1.1-Operation-Types)** **** based on the risk pattern you want to control. * Number of transactions * Sum of transaction amount * Associative Constraints ### Step 4. Configure Levels and Attributes/ Sub-levels Levels define **the scope at which a counter is evaluated** , attributes and sub-levels further narrow this scope by applying specific transaction characteristics like payment method, card type, or instrument. ![Image](https://dth95m2xtyv8v.cloudfront.net/tesseract/assets/juspay-frm/Screenshot%202026-01-21%20at%204.31.07%E2%80%AFPM.png) *Level and sub-levels configuration* **Configuration in this step** * **Level:** Payment Related * **Payment Method Type:** Card * **Card Type:** Credit Card * **Payment Method:** VISA, MASTERCARD, MAESTRO or others * **Payment Method Instrument:** `CardIdentifier` #### Interpretation With this configuration, the counter is applied **at the card level** and evaluates **credit card transactions** for the selected card schemes. Each unique card is tracked independently based on its card identifier. ### Step 5. Add Conditions Conditions filter **which transactions are counted** it reduces the noise and improve the accuracy. Some common conditions: ![Image](https://dth95m2xtyv8v.cloudfront.net/tesseract/assets/juspay-frm/Screenshot%202026-01-21%20at%204.29.37%E2%80%AFPM.png) *Configuring Conditions* **Example Condition** * **Attribute:** Amount * **Operator:** Greater than or equal to (`>=`) * **Value:** `10,000` #### **Interpretation** Only transactions with a cart amount of **₹10,000 or more** are considered for this counter. Transactions below this amount are excluded from evaluation. ### Step 6. Threshold Configuration A **threshold** defines the **acceptable limits for a counter** and determines **how the system should respond** when those limits are reached or exceeded. ![Image](https://dth95m2xtyv8v.cloudfront.net/tesseract/assets/juspay-frm/Screenshot%202026-01-21%20at%204.30.02%E2%80%AFPM.png) *Configuring Threshold* **Configuration in this step** * **Range 1:** 0–5 → PASSED * **Range 2:** >5 → REJECTED #### **Interpretation** This configuration enforces a **maximum of 5 transactions per card per day** . Any transaction attempt beyond this limit is **rejected immediately** during pre-transaction evaluation. ### Step 7. Configure Reset Window and Reset Period The reset window defines the **time duration for which counter values are considered** . ![Image](https://dth95m2xtyv8v.cloudfront.net/tesseract/assets/juspay-frm/Screenshot%202026-01-20%20at%205.54.04%E2%80%AFPM.png) ### **Configuration in this step** * **Reset Window Type:** Dynamic Window * **Reset Period:** Daily (or weekly, monthly, yearly, custom) ### **Interpretation** With a **dynamic reset window** , the counter resets based on its creation time and the configured **reset period** . In this configuration, a **daily reset period** ensures the counter to reset every 24 hours for the program. This ensures that counter values are evaluated **within the defined reset window** and are automatically cleared when the reset period expires. To learn more, go to _[Detailed Explanation](https://juspay.io/in/docs/juspay-frm/docs/program-management/configuration-elements#5.-Configuring-Reset-Window-and-Reset-Period)_ ### Step 8 Enable Customer Blacklisting (Optional) Customer blacklisting can be enabled for both pre-transaction and explicit counters. It’s an optional configuration that can be enabled based on the specific requirements. ![Image](https://dth95m2xtyv8v.cloudfront.net/tesseract/assets/juspay-frm/Screenshot%202026-01-20%20at%206.00.50%E2%80%AFPM.png) #### **Interpretation** When enabled, breaching the configured threshold results in the **customer being blocked from further transactions** . The block remains in effect until it is **manually removed** . See how to **[Manage Blacklisted Customers](https://juspay.io/in/docs/juspay-frm/docs/program-management/elements-involved#6.1-Managing-Blacklisted-Customer)** [.](https://juspay.io/in/docs/juspay-frm/docs/program-management/elements-involved#6.1-Managing-Blacklisted-Customer) This allows automatic enforcement against repeated or high-risk behavior without additional intervention. --- ## Demo Video ### 1. Pre-Transaction Counters This example demonstrates how a **Pre-Transaction Counter** can be used to **limit daily credit card transactions** and prevent excessive or abusive usage before the transaction is sent to the payment gateway. [Video](https://dth95m2xtyv8v.cloudfront.net/tesseract/assets/juspay-frm/Filter%20Check%20(12).mp4) #### Use Case A merchant wants to **restrict the number of high-value credit card transactions per day** to control risk during high-traffic periods or promotional events, while still allowing genuine customer activity. #### Rule Engine Behaviour * Allows up to **5 transactions per day** per configured scope * Immediately **rejects subsequent transactions** once the threshold is exceeded * Automatically **resets the count every 24 hours** based on the dynamic reset window ### 2. Configuring Explicit Counters This example demonstrates how an **Explicit Counter (Post-Transaction Counter)** can be used to **temporarily block customers after multiple failed transactions** . #### Usecase A merchant wants to prevent repeated failed payment attempts that may indicate abuse or automation. [Video](https://dth95m2xtyv8v.cloudfront.net/tesseract/assets/juspay-frm/Filter%20Check%20(1).mp4) #### **Rule Engine Behaviour:** * Continuously tracks failed transaction outcomes per customer * Permits a limited number of failures to accommodate genuine errors * Temporarily restricts further transactions once the failure threshold is exceeded * Automatically lifts the restriction after the configured cooldown period --- ## See Also - [Elements Involved](https://juspay.io/in/docs/juspay-frm/docs/program-management/elements-involved) - [Configuring Comparator](https://juspay.io/in/docs/juspay-frm/docs/program-management/configuring-comparator)