Policy Management

A policy defines the permissible behavior of an account in every financial and non-financial transaction. It is a mechanism to define the following:

• Permissible account holders
• Permissible transactions
• Acceptable velocity and volume of such transactions

It can also help monitor or control the balances. The policy provides a way to deny transactions or notify of any deviations. A policy also encompasses the rules to define the fees and charges applicable for various transactions. Policies could be used to define and alter the basic business rules of the products, the risk management for the product, and to monitor the utilisation of products.

Issuance Policy

Issuance policy enables issuers to configure the criteria for an account holder to be eligible for availing of a product. Using this policy, issuers can configure policies with the following types of conditions:

• Demographics of the account holder
  Example: Woman of age > 24 with Professions such as [Doctor, Lawyer] residing in New York
• Credit Score
  Example: Credit score > 720
• Fields in the Credit report
  Example: Credit utilization ratio < 0.2

Minimum Amount Due (MAD) Policy

The MAD policy enables issuers to define how the minimum due amount should be computed for an account at the end of a billing period. Issuers can define different formulas for computing the minimum due amount based on the delinquency level of the account. Example:

• For accounts that are not delinquent or delinquent for less than 60 days:
  MAD = 5% Retail Purchases + 100% Cash Advances + 100% Pending EMI
• For accounts that delinquent for more than 60 days:
  MAD = 100% Retail Purchases + 100% Cash Advances + 100% Pending EMI

Fee & Charges Policy

Fee policy can be used to define all the fee & charges that should be levied on the account belonging to a product. All fee can be broadly classified into two categories:

• **Transaction-based fee:**
  This is the type of fee that is levied in response to the successful posting of a transaction on an account. Currently, Fusion supports the following transaction-based fees:
  • Cash Advance fee
  • Foreign Currency Fee
  • Wallet Loading Fee
• Relationship-based fee:
  This type of fee is levied in response to any non-financial activity on the account. Currently, Fusion supports the following relationship-based fees:
  • Annual membership fee
  • Late payment fee
  • Overlimit fee
  • Payment return fee
  • Card re-issuance fee

For both categories of fees, issuers can specify the following:

• Fee computation Model
  This is used to arrive at the exact charge that should be levied on the account. Currently, the following fee computation models are supported:
  

  • Fixed: Fixed fee would be charged every time.
  • Tiered: Fee is charged based upon tiers.
  • Percentage / Max: Fee would be computed as a percentage. However, the amount levied would not exceed a provided maximum value.
  • Percentage / Min: Fee would be computed as a percentage. However, the amount levied would not go below a provided minimum value.

• Waiver conditions
  This can be used to define the conditions when the fee shouldn’t be charged.

• Tax
  This can be used to specify the tax that has to be levied along with the fee. Tax can be computed as a fixed value or percentage of the fee.

• Usury limits
  This can be used to provide the upper limit of the aggregate fee that can be levied on the account within a time frame (day, week, month, year).

Interest Policy

Interest policy enables issuers to configure how the interest would be levied on an account for a given product. Issuers can configure the following using an interest policy:

• Define fixed or variable interest rates to be levied for the following:
  • Purchase balances
  • Cash advances
  • Balance transfer amount
• Define penalty rates to be levied in case the account holder defaults on making the minimum amount due by the due date.
• Define time-bound introductory rates to be levied for new accounts.

Statement Policy

Statement policy enables issuers to define the visual template of the statement that would be generated for an account at the end of the billing period. On the statement day, this template is filled with the actual account information to generate a statement file. This file would be sent to the account holder on various channels configured by the issuer. This policy also contains the following configurations:

• Valid billing cycles - Issuers can define billing cycles from which account holders can select their preferred billing cycle. Currently, Fusion Credit supports 28 monthly billing cycles, starting 1st-28th day of the month
• Grace days - Issuers can select the number of grace days.
• Payment due days or payment due date - Issuers can provide a fixed date as the due date for paying off the minimum due or provide a fixed number of due days. In the latter case, due date could be different every month due to the different number of days every month.
• Statement delivery channels - Issuers can specify the channels on which the statement should be sent to the account holder. Example: SMS, email, Whatsapp, and mail.

Account Classification Policy

Account classification policy enables issuers to configure parameters required to classify the account into various states. Fusion Credit provides the following account classification types:

Independent classification
This type of classification depends on the single or multiple attributes of the account. Following independent classifications are provided out of the box:

Dependent classification
This type of classification can depend on single or multiple attributes of the account as well as the dependent classification states. The following dependent classifications are provided out of the box:

Account Flags Policy

Account flags policy enables the Issuer to configure the actions that are to be restricted for accounts based on their current state. Using this policy, the issuer can define condition-action pairs for accounts and cards. Every condition-action pair would have the following components:

• Condition: Logical conditions on the status of the account. Every condition is composed of the following 3 parts:
  • Variable: Account status (Delinquency status, Balance status, Administrative status)
  • Operator: =, <, >, In, Not In
  • Value: Value of the status
• Actions: List of actions that will be executed if the condition is true

Example: The following can be defined using the account flags policy:

Repayment Policy

Repayment policy enables the Issuer to define the hierarchies in which any repayment, made by the account holder, would be apportioned on the account balances. Following configurations are supported in the repayment policy:

• Multiple hierarchy based upon the delinquency level of the account. Example:
  

  • For accounts that are not delinquent or are delinquent for less than 60 days:
    Hierarchy = fee charges → interest charges → EMI → retail purchases → cash advance
  • For accounts that are delinquent for more than 60 days:
    Hierarchy = retail purchases → cash advance → EMI → fee charges → interest charges

• Separate hierarchy for repayment amount < minimum due and the remaining amount over minimum due. Example:
  

  • Hierarchy for amount < Minimum due
    fee charges → interest charges → EMI → retail purchases → cash advance
  • Hierarchy for amount > Minimum due
    retail purchases → cash advance → EMI → fee charges → interest charges

Note: These are just indicative repayment hierarchies. The real hierarchy would have a lot more items.

Delinquency Policy

Delinquency policy enables issuers to configure the delinquency levels and “days past due” range for every delinquency level. Issuers can also specify the variance amount, which is the minimum amount that should be there in any delinquency bucket. Delinquency aging is done on the due date. Reaging of delinquency happens on every repayment that is posted to the account. Delinquency for every account is reported as:

1. Days past due: Provides the date range for which the account is past due
2. Cycles past due: Provides the billing periods for which the account is past due

Delinquency Restructuring Policy

Delinquency restructuring policy enables issuers to provide configurations to write off the current debt and create a new debt on the account so as to make it look good on books.

Example: The following table can be configured by issuers as a part of this policy.

This means, for a delinquent account that has total dues lying between $10,000 and $20,000 → issuers would charge $1,000/- to restructure the debt on the account and make the entire amount as current due.

Spend Limit Policy

Spend limit policy enables issuers to put spend limits on the account and card. There are limits that are put on the account on creation. Issuers can define whether or not such limits can be overridden by the account holder. At any point in time, the most restrictive limits would be applicable on the account. Fusion Credit supports the following limit configurations:

• Spend limits on the account
• Spend limits on primary or add-on card
• Spend limits based on channel of initiation - ATM / POS / online / contactless

Spend limit can be of the following types:

• Per transaction value
• Aggregated value over a day, week, or month
• Maximum count in a day, week, or month

Example: Set an aggregate limit of $5000/- per day for all the online transactions happening via an add-on card. Set an aggregate limit of $20,000/- per month for all the POS transactions happening on the account.

Credit Limit Update Policy

Credit limit update policy enables issuers to configure the conditions for an account to be eligible for a credit limit update and the bounds within which the limit can be updated. Fusion Credit supports configurations for the following type of credit limit update:

• Temporary increase
• Permanent increase

The following are the configurations that can be done for both types of update:

• Minimum month on books
• Minimum assessment period
• Maximum percentage of increase (only for temporary increase)
• Minimum duration of increase (only for temporary increase)
• Maximum duration of increase (only for temporary increase)

Account Closure Policy

Account closure policy enables issuers to define account closure workflows. Issuers can configure different workflows for different reasons of account closure. Fusion Credit currently supports the following reason codes:

• Bank-initiated - This is when an issuer decides to terminate the account services. The most common reasons for this being:
  • Death
  • Delinquency
  • Probate
  • Bankruptcy
• User-initiated - This is when an account holder doesn’t want to avail of services offered by the bank and hence requests for closure of the account.

For workflows of each of the supported reason codes, issuers can configure:

1. Pre-conditions for initiating the workflow
   Example: Number. of unsettled transactions should be 0, number of unresolved disputes should be 0.

2. Activities to be done as a part of the workflow
   Example. Different handling of accounts in debit balance and credit balance, disabling of all the associated cards, stopping the generation of statement for the account, stopping rewards accrual, etc.

3. Post workflow completion activities
   Example: Informing any external system of the successful account closure via webhook.