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

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

Transaction policy

Transaction Policy is a set of rules that you apply on an entity's transactions. Transaction policy can be configured at various entity levels like Product Family, Product, Account Holder and Account.

Some of the common use-cases include:

• Blocking/unblocking ATM, e-commerce, and POS 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 transaction attributes. Transaction Category can be created at various entity-levels like Account Holder, Product and Product Family.

Transaction Category must be created before creating 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 on ATM transactions.

Transaction policy constraints

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

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 specify the maximum amount allowed and minimum required amount 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 applied over the volume or the velocity(count) of transaction. They can be applied for multiple actions (DEBIT, CREDIT) and Transaction Categories . Aggregation of transactions can be performed over a DAY, WEEK, MONTH, QUARTER or YEAR.
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

aggExpressionID is mapped to an expression code. 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
}
]

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.

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 an Account Holder or Account level.