Switch to dark theme

Switch to light theme

About Policies

About Policies
Published on 20th August, 2021

Discover the important functional concepts related to transaction policies and their constraints. In this article, you learn about:

Transaction policy

Transaction Policy is a set of rules and conditions that you can apply on an entity’s transactions at various entity levels like Product Family, Product, Program, Account Holder and Account.

Some of the common use-cases include:

  • Blocking/unblocking ATM, e-commerce, and POS transactions.

  • Disallowing spends on a debit card after a certain time period.

  • Setting daily, weekly, monthly or yearly transaction count limits.

  • Setting minimum/maximum balance amount.

Transaction category

Transaction Category is used to group transactions based on various qualifying criteria. The criteria include transaction types like domestic, contactless transactions and payment instrument attributes like card number.

You can create a Transaction Category using any combination of these attributes. Transaction Category can be created at various entity-levels like Account Holder, Product and Product Family.

Transaction Policy is applied to the Transaction Category, and therefore Transaction Category must be created before creating and mapping the Transaction Policy.

For example, you can create a Transaction Category that groups all ATM transactions for a customer’s prepaid card. You can then apply policies to set maximum withdrawal limit and withdrawal count on the card.

Transaction policy constraints

Transaction policies contain multiple transactions, aggregation and balance constraints that dictate whether to allow or disallow transactions. Each of these constraints is explained below:

Policy violation actions

There are three types of actions that can be applied when constraints specified in a Transaction Policy are violated. Each action has a particular behaviour, as explained below:

Action Behaviour
DECLINE Default action. Decline the transactions and throw specific error code.
NOTIFY Permit the transaction, but notify of the violation.
DECLINE_AND_NOTIFY Default action. Decline the transactions and throw specific error code.Along with Decline, Notify the violation as well.

To allow for flexibility for notification delivery, Fusion posts a message to the alert stream. The notification system specific to the issuer is expected to monitor these alerts and take corresponding notification steps. Additionally, an HTTP endpoint can also be configured in the policy for policy violation notifications.

Transaction constraints

Transaction Constraints are the basic attributes that must be specified while creating a Transaction Policy for an entity. These constraints include debit or credit transactions, Transaction Categories*, time period and error code to be invoked when the policy is violated.

Transaction limits

Transaction Limits are policy constraints that specify the maximum amount allowed and minimum amount required per transaction. They can be applied for multiple actions ( DEBIT , CREDIT ) and multiple Transaction Categories allowed in the Transaction Constraints.

Transaction limits
Switch Theme
Expand More
Copy
"txnLimits": [
{
"action": "DEBIT",
"categoryCode": "ECOM_1112",
"errorCode": "GENERIC_ERROR",
"maxAllowedAmount": 1000000, /*In paise for India*/
"minRequiredAmount": 0 /*In Paise for India*/
}
]
Code Copied

Aggregation constraints

Aggregation Constraints are transaction limits that accumulate over the count or total volume of the transactions. They can be applied for multiple actions (DEBIT, CREDIT) and multiple Transaction Categories allowed in Transaction Constraints.

Aggregation can be performed over a DAY, WEEK, MONTH, QUARTER or YEAR.

For example, if you create a policy on the 14th of Feb 2020, monthly aggregation will provide count/volume from 1st Feb 2020 to 29th Feb 2020.

This works by following the calendar configuration configured in the Chart of Accounts. The same logic is used for other aggregation units as well.

Aggregation expression

Before we dig deeper into understanding what kind of aggregation expressions Fusion provides, keep in mind the following points:

  • Uncaptured payments are those that are not acknowledged by the Payee. These payments are auto-reversed after a certain duration.

  • credit reversals is a debit posting due to a credit being reversed.

  • debit reversals is a credit posting due to a debit being reversed.

In accordance with the above, for every IFI, following aggregate expression code are defined in fusion:

code Description
1 Sum of debits except uncaptured ones, (excludes credit reversals as well)
2 Sum of credits except uncaptured ones, (excludes debits reversals as well)
3 Count of debits except uncaptured ones, (excludes credit reversals as well)
4 Count of credits except uncaptured ones, (excludes debit reversals as well)
5 Sum of debits that are not reversed or are reversals
6 Count of debits that are not reversed or are reversals
7 Sum of credits that are not reversed or are reversals
8 Count of credits that are not reversed or are reversals

Examples:

Velocity Constraints
Switch Theme
Expand More
Copy
"velocityLimits": [
{
"action": "DEBIT",
"aggExpressionID": 6,
"categoryCode": "ECOM_1112",
"dailyLimit": 10,
"errorCode": "GENERIC_ERROR",
"monthlyLimit": 30,
"quarterlyLimit": 90,
"type": "VELOCITY",
"weeklyLimit": 20,
"yearlyLimit": 100
}
]
Code Copied
Volume Constraints
Switch Theme
Expand More
Copy
"volumeLimits": [
{
"action": "DEBIT",
"aggExpressionID": 8,
"categoryCode": "ECOM_1112",
"dailyLimit": 10000,
"errorCode": "GENERIC_ERROR",
"monthlyLimit": 200000,
"quarterlyLimit": 500000,
"type": "VOLUME",
"weeklyLimit": 120000,
"yearlyLimit": 1000000
}
]
Code Copied

Balance constraints

Balance Constraints are limits applied on the underlying current balance of the account/ledger in the system that is used to perform the transaction. You can specify maximum allowed balance and minimum required balance, before and after a transaction. If and when these constraints are violated, the transaction is allowed or disallowed based on the action specified.

Similar to some of the above-mentioned constraints, they can be applied for multiple actions ( DEBIT , CREDIT ) and multiple Transaction Categories allowed in Transaction Constraints.

Example:

Volume Constraints
Switch Theme
Expand More
Copy
"balanceLimits": [
{
"action": "DEBIT",
"errorCode": "GENERIC_ERROR",
"maxAllowedBalance": 1000000,
"maxAllowedBalanceBeforeTxn": 20000,
"minRequiredBalance": 10000,
"minRequiredBalanceBeforeTxn": 5000,
"transactionCategory": "ECOM_1112"
}
]
Code Copied

Validity constraints

The validFrom and validUntil constraints are used to specify the expiry of the transaction policy in epoch time. If not provided, the default time period of 5 years from the time of creation is applied. Alternatively, these can be provided as valid epoch times to the function.

Control spends

Periodic and Aggregate policies

You can specify the volume and velocity of transactions permitted over a time period, grouped by any attribute of the transaction and could be applied to an Account or an Account Holder . The policy can be applied at a Product Family, Product, Program or Account level.

Applied at Applicable to Effect
Program
Account
The aggregate value of transactions of the Account participating in the transaction are used to evaluate the rules. The Account is associated with this Program.
Product Family Account The aggregate value of transactions of the Account participating in the transaction are used to evaluate the rules. The Account is associated with a product that is part of this Product Family.
Product Account The aggregate value of transactions of the account participating in the transaction are used to evaluate the rules. The account is associated with this Product.
Account Account Account The aggregate value of transactions for an Account are used to evaluate the rules
Program Account Holder The aggregate value of transactions of all Accounts of the Account Holder associated with this Program are used to evaluate the rules.
Product Family Account Holder The aggregate value of transactions of all Accounts of the Account Holder within this Product Family are used to evaluate the rules.
Product Account Holder The aggregate value of transactions of all Accounts of the Account Holder of this Product are used to evaluate the rules.
Account Account Holder
N/A

Common use-cases and examples:

  • Do not permit more than 10000 deposits per month into minimum KYC-ed prepaid accounts.

  • Do not permit more than 25000 deposits through prepaid cards in a month.

  • Do not permit more than 15 spends per day per Account Holder.

  • Do not permit more than 30000 spent at fuel stations in a quarter.



Related articles