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

• Transaction policy
• Transaction category
• Transaction policy constraints
• Control spends

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/international, 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:

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, Fusion provides the following 4 aggregation expression codes :

• Sum of all the debits from captured payments that are not reversed or credit reversals.
• Count of all the debits from captured payments that are not reversed or credit reversals.
• Sum of all the credits from captured payments that are not reversed or debit reversals.
• Count of all the credits from captured payments that are not reversed or debit 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.

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.