About Policies
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.
"txnLimits": [
{
"action": "DEBIT",
"categoryCode": "ECOM_1112",
"errorCode": "GENERIC_ERROR",
"maxAllowedAmount": 1000000, /*In paise for India*/
"minRequiredAmount": 0 /*In Paise for India*/
}
]
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:
"velocityLimits": [
{
"action": "DEBIT",
"aggExpressionID": 6,
"categoryCode": "ECOM_1112",
"dailyLimit": 10,
"errorCode": "GENERIC_ERROR",
"monthlyLimit": 30,
"quarterlyLimit": 90,
"type": "VELOCITY",
"weeklyLimit": 20,
"yearlyLimit": 100
}
]
"volumeLimits": [
{
"action": "DEBIT",
"aggExpressionID": 8,
"categoryCode": "ECOM_1112",
"dailyLimit": 10000,
"errorCode": "GENERIC_ERROR",
"monthlyLimit": 200000,
"quarterlyLimit": 500000,
"type": "VOLUME",
"weeklyLimit": 120000,
"yearlyLimit": 1000000
}
]
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:
"balanceLimits": [
{
"action": "DEBIT",
"errorCode": "GENERIC_ERROR",
"maxAllowedBalance": 1000000,
"maxAllowedBalanceBeforeTxn": 20000,
"minRequiredBalance": 10000,
"minRequiredBalanceBeforeTxn": 5000,
"transactionCategory": "ECOM_1112"
}
]
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 |
|
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 |
|
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
Transaction Policy FAQs
FAQs related to the transaction policy APIs
Fusion Events
List of webhooks to subscribe to & receive event notification
Account APIs
Create Accounts, manage Bundles, view transactions
Transaction Policy Error Codes
List of error codes specific to Transaction policy APIs
Transaction Policy APIs
Control spends, configure rules to allow/disallow transactions
Transaction Policies
Step-by-step guide on transaction policy configuration