--- page_title: Counter Types product: Juspay FRM page_source: https://juspay.io/in/docs/juspay-frm/docs/program-management/counter-types llms_txt: https://juspay.io/in/docs/llms.txt product_llms_txt: https://juspay.io/in/docs/juspay-frm/llms.txt --- # Counter EvaluationTypes FRM Counters can be evaluated at different stages of the transaction lifecycle depending on the risk control required. Based on **when the counter is evaluated** , Juspay FRM supports two types of counters: 1. **[Pre-Transaction Counters](https://juspay.io/in/docs/juspay-frm/docs/program-management/counter-types#1.-Pre-Transaction-Counters%E2%80%8B)** [:](https://juspay.io/in/docs/juspay-frm/docs/program-management/counter-types#1.-Pre-Transaction-Counters%E2%80%8B) Evaluated before the payment gateway is called which proactively **block or flag transactions before processing** , and 2. **[Explicit Counters (Post-Transaction Counters):](https://juspay.io/in/docs/juspay-frm/docs/program-management/counter-types#2.-Explicit-Counters-(Post-Transaction-Counters)%E2%80%8B)** Explicit counters**** is used when conditions depend on statuses (i.e **Transaction Outcomes** ) such as _Authentication Failed, Juspay Declined, Authorization Failed_ , or _Failed_ . --- ## 1. Pre-Transaction Counters Pre-transaction counters are evaluated **before a transaction is sent to the payment gateway** .These counters are used to **enforce limits in real time** and prevent transactions from being processed once configured thresholds are exceeded. [Video](https://dth95m2xtyv8v.cloudfront.net/tesseract/assets/juspay-frm/Pre.mov) ### 1.1 Operation Types Pre-transaction counters support multiple operations to address different risk patterns. ![Image](https://dth95m2xtyv8v.cloudfront.net/tesseract/assets/juspay-frm/Screenshot%202026-01-12%20at%2012.02.05%E2%80%AFPM-jEPzK.png) ## Number of Transactions Applies on number of transaction **Use cases** * Transaction rate limiting * Retry and attempt controls * Per-customer or per-device limits **Example:** Allow a customer to initiate only 5 transactions per day. ## Sum of Transaction Amount Accumulates the total transaction value over time. **Use cases** * Daily or hourly spend limits * Exposure control for offers or incentives * Preventing split-payment abuse **Example:** Restrict total customer spend to ₹10,000 per day. ## Associative Constraints Tracks the number of unique relationships between entities. **Typical use cases** * Detecting multiple bank accounts per customer * Identifying account or device sharing * Flagging structured or organised abuse **Example:** Block transactions when a customer is linked to more than 5 unique VPAs in a day. ### 1.2 When to Use Pre-Transaction Counters Use pre-transaction counters when you need to: * **Block transactions immediately** once a configured limit is reached * Enforce **maximum transaction limits** , such as the number of transactions allowed per day * Apply **rate or frequency controls** across customers, cards, devices, or IPs * Prevent **excessive retries or rapid** transaction attempts * **Restrict cumulative transaction usage** to prevent abuse of promotional or incentive-based benefits ### 1.3 Key Characteristics * Evaluated **before** the payment gateway is called * Can **block or flag** the current transaction * Do not require knowledge of the transaction result * Ideal for **real-time enforcement** and load protection Pre-transaction counters are typically used as the **first line of defense** in the FRM rule engine to stop high-risk or abusive behaviour early in the transaction lifecycle. --- ## 2. Explicit Counters (Post-Transaction Counters) Post-transaction counters, also referred to as **Explicit Counters** , **after a transaction has been processed** and its final outcome is known. These counters track specific transaction results and are used to control **subsequent transaction behaviour** rather than the current transaction. ![Image](https://dth95m2xtyv8v.cloudfront.net/tesseract/assets/juspay-frm/Screenshot%202026-01-12%20at%2012.13.16%E2%80%AFPM.png) *Explicit Counter Statuses* ![Image](https://dth95m2xtyv8v.cloudfront.net/tesseract/assets/juspay-frm/Screenshot%202026-01-19%20at%203.07.31%E2%80%AFPM%201-Dwmkf.png) *Explicit Counter Configuration with Operations (Levels & Conditions)* ### 2.1 Supported Transaction Outcomes Explicit Counters let you track specific **transaction outcomes (statuses)** using [supported operations](https://juspay.io/in/docs/juspay-frm/docs/program-management/counter-types#1.1.1-Supported-Operations) such as **Number of transactions** , **Sum of transaction amount** , and **Associative Constraints** . You can configure an Explicit Counter for any one of the following **statuses** : * **Authentication Failed** * **Juspay Declined** * **Authorization Failed** * **Failed** > **Note** > > #### Example: Configure an Explicit Counter (Authentication Failed) > > > > ![Image](https://dth95m2xtyv8v.cloudfront.net/tesseract/assets/juspay-frm/Screenshot%202026-01-19%20at%203.50.06%E2%80%AFPM.png) > *Example Configuration for Explicit Counter* > > > > In this configuration, you create an **Explicit Counter** for the **Authentication Failed** transaction outcome and track the **Number of transactions** . > > You then define **threshold ranges** to decide the action: > > * **0 to 5** → **PASSED** > * **6 and above** → **REJECTED** > > Next, you configure the **Reset Window Type** as **Dynamic Window** with a **Reset Period** of **7200 seconds (2 hours)** .This means the counter resets **2 hours from the time it is created/first triggered** , and the thresholds apply within that window. > > Optionally, you can enable **Customer Blacklisting** so that when the counter breaches the configured threshold, the customer is blacklisted automatically. ### 2.2 When to Use Explicit Counters Use explicit counters when you need to: * Limit **repeated authentication or authorization failures** * Prevent **infinite retry loops** caused by automated or abusive behaviour * Enforce restrictions **based on transaction outcomes** , not just attempts * Protect issuer, network, and authentication systems from repeated failures * Apply temporary blocks after multiple failed transaction outcomes ### 2.3 Key Characteristics * Evaluated **after the transaction outcome is determined** * Do **not affect the current transaction** * Influence the handling of **future transactions** * Enforced until a reset condition is met --- ## See Also - [Overview](https://juspay.io/in/docs/juspay-frm/docs/program-management/overview) - [Elements Involved](https://juspay.io/in/docs/juspay-frm/docs/program-management/elements-involved)