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. Transaction policy can be configured 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.transac tions
• Allowing/disallowing transactions during defined time slices
• Setting daily, weekly, monthly or yearly transaction volume and velocity(count) limits.
• Setting minimum/maximum balance amount.

Transaction category

Each transaction has attributes which specify details about the transaction.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. Transaction Policy is applied to the Transaction Category. 

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 cardon ATM transactions.

Transaction policy constraints

Transaction policies contain multiple transactionstransaction, balance and aggregation and balance constraints that dictate determine 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:

DECLINE

Default action. Decline the transactions and throw specific error code.

NOTIFY

Permit the transaction, but notify of the violation.

DECLINE_AND_NOTIFY

Decline the transaction and notify of the decline.

Transaction constraints

Transaction constraints

Transaction Constraints help configure allowed and disallowed Transaction Categories, allowed and disallowed time slices. You specify the action(DEBIT/CREDIT) for which you wish to configure transaction constraints. Time slices are specified in the crontab format.  You also specify error code to be thrown when the transaction constraints are violated.

Transaction limits

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

for a transaction. You specify the action(DEBIT/CREDIT) for which you wish to configure transaction limits. You specify the Transaction Categories  for which you want these transaction limits to be applied.  You also mention the specific error code, which needs to be thrown when transaction limits are violated.

"txnLimits": [
{
"action": "DEBIT",
"categoryCode": "ECOM_1112",
"errorCode": "GENERIC_ERROR",
"maxAllowedAmount": 1000000, /*In paise for India*/
"minRequiredAmount": 0 /*In Paise for India*/
}
]

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.

They can be applied for multiple actions ( DEBIT , CREDIT ) andTransaction Categories .

Example:

"balanceLimits": [
{
"action": "DEBIT",
"errorCode": "GENERIC_ERROR",
"maxAllowedBalance": 1000000,
"maxAllowedBalanceBeforeTxn": 20000,
"minRequiredBalance": 10000,
"minRequiredBalanceBeforeTxn": 5000,
"transactionCategory": "ECOM_1112"
}
]

Aggregation constraints

Aggregation Constraints are transaction limits that accumulate applied over the count or total volume of the transactionsvolume or the velocity(count) of transaction. They can be applied for multiple actions (DEBIT, CREDIT) and multiple Transaction Categories allowed in Transaction Constraints . Aggregation of transactions 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 Credit reversals is a debit posting due to a credit being reversed.
• debit Debit reversals is a credit posting due to a debit being reversed

aggExpressionID is mapped to an expression code.

In accordance with the above, for every IFI, Fusion provides the following 4 aggregation expression codes :

Currently Fusion supports 8 expression codes.

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.

Policy violation actions

There are three types of actions that are taken when constraints specified in a Transaction Policy are violated. The table explains the policy violation actions.

An HTTP endpoint can be configured for policy violation notifications.

Policy Applicability

The policy can be applied at a Product Family, Product, Program an Account Holder 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.