Payment Rules
The Payment Rules Property Class is used by Products, which have amounts billed and made due from the customer.
An arrangement may have several bills outstanding and each bill may comprise multiple amounts (For example, principal, principal interest, penalty, tax, charges, and so on). When a customer makes a payment, the entire due amount may not be satisfied. The Payment Rules Property Class is used to define the method by which a single payment is applied to multiple bills and multiple amount types.
Product Lines
The following Product Lines use the Payment Rules Property Class:
- Accounts
- Agent
- Asset Finance
- Deposits
- Facility
- Lending
- Safe Deposit Box
Property Class type
The Payment Rules Property Class uses the following Property Class Types:
- Dated
- Enabled For Memo
- Multiple
- Tracking
Property Type
The Payment Rules Property Class is associated with the PRODUCT.ONLY Property Type.
Balance Prefix and Suffix
The Payment Rules Property Class is not associated with balance prefix and suffix.

The attributes of the Payment Rules Product Condition are explained below.

This field is used to define different payment allocation rules that are to be setup for performing assets and non-performing assets. It forms part of an associated multi-value set to indicate if the set of fields are applied for either performing assets or non-performing assets or both
- Performing - The rules stated under this multi-value are used when the repayment happens on the contract when the contract is not suspended. Just like normal repayment of a DUE bill.
- Suspended - The rules are applicable only when the contract is under suspension. The allocation themselves might be different – but the working of the payment rules component as such does not change
- Both - System uses the same rule stated under it for both Suspension and performing loans(indicating, the bank does not want to differentiate its repayment between performing or suspended loans). For upgrading clients, using Payment Rules, the conversion routine is used to tag this option by default.
- Restructure - The rule is applicable when the contract is in Restructure status (that is, it is undergoing Loan Restructuring). Set-up of a restructure-specific rule is possible only if the product under which the loan is booked has Restructure Rules property class linked to it.
Read Restructure Rules Property Class and Loan Restructuring for more information.

The value in the attribute must be a valid record in AA.PAYMENT.RULE.TYPE . It decides the PAYMENT.RULES to be applied for an arrangement.Available values are:
- BALANCES – Payment is applied on arrangements current balances..
- BILL.PROPERTY - Payments to due amounts is Property wide (Interest Property, Account Property).
- BILL.DATE - Payment to due amounts is date wise.
- PAY.IN.ADVANCE – Indicates the amount should go in to UNC balance.
- ADVANCE - The payment amount is applied on the arrangement current balances of interest, account properties and advance due balances for charge properties. System raises future bills in advance and these bills are both in SETTLED and ADVANCED status. It can be set only for the PAYMENT Bill types and valid only for DUE payment method. The Property must belong to system calculated payment types and any charges. It is valid when a bill is in ISSUED status.

This field is used to indicate the order in which system can allocate the payment received against multiple bills that are pending settlement. When there is more than one bill outstanding, the order of settlement can either be OLDEST.FIRST and OLDEST.LAST.

When there are multiple bills due on the same date, the payment rules can decide if the bill with the highest or lowest amount should be settled first. The Repayment Order attribute can be set as lowest and highest.
- It allows the definition of repayment order for settlement of bills on the same due date based on total bill amount.
- When the bills are partially settled, the prioritisation is based on the outstanding bill amount as the highest or lowest amount first.
- It can be set only for Bill by Type and Bill by Property Payment Rule types. When this attribute is not set, the system randomly assigns the repayment order which is based on the order in which bill was generated.

Tax on interest and charge component can be settled in a pro-rated fashion or can be settled separately.The Tax Settlement attribute can be set as :
- Separated - Tax Property can be sequenced in the Property field in Payment Rule product condition.This feature to settle tax separated is not applicable for advance and principal decrease payment rule type.
- Prorate - This option is the default option when this field is not set. When set as Prorated, tax is calculated and collected on a pro-rated method based on the repaid amount.

Allows the user to specify the Property sequence in which the balances get affected during repayment. This is associated with the Property attribute.

The Attribute along with the Sequence attribute is used to specify the sequence in which the balances can be settled.

When the Prop Appl Type attribute is set as BALANCES, this attribute allows the balance type of the arrangement to be defined that is used for payment allocations
- This attribute becomes mandatory when Prop Appl Type is set as BALANCES.
- The value must be a valid balance type in AC.BALANCE.TYPE.
- System allows only the balance types with the prefix CUR, ACC, RES, REC.

Represents the balances to be paid for the defined Property. When the Property application type is set to BALANCE, then balance type can be specified and rules allocation happens based on the balance type specified.

This attribute is used to handle remainder of funds when a payment is made which satisfies all of the due and overdue amounts and there is a remainder of funds (that is, an overpayment).
This is handled by specifying the Activity to be processed for the remainder of the payment, subject to transaction Rules.
If the transaction fails, the remainder amount is processed by the Default Activity specified in Accounting.

This attribute denotes how the repaid amount should be applied to produce the future bills in advance. Available values are:
- Full – The PAYMENT.RULES is applicable only if the amount can fully settle future scheduled bills. The bill status is SETTLED.
- Partial – The System settles to the extent of the repaid amount and the bill status is ADVANCED.

Allows the user to specify whether bill to be raised for amount adjusted through reminder Activity.
In the case, where billed amounts exist but the due date has not yet been reached, user can determine that the billed amounts can be made due up to the amount of any remaining payment.
This allows for the processing of bill payments which are received prior to the due date.

This field provides restriction on the type of bills that can be settled in advance payment. This field has the following options:
- NULL – Settles current bill and creates and settles bills until all the payment amount is utilised.
- BILLED – Settles current bill, sends the remaining to remainder activity.
- # (1 to N) – Settles current bill + n bills and sends the remaining to remainder activity.

This attribute is associated with the Advance Payment attribute. When the attribute is checked, it denotes payment can be made more than the accrued interest. This is applicable for both conventional loans as well as Islamic contracts (fixed interest method).
- In the fixed interest method, the total profit amount for the arrangement is known. The system ensures that the accrual happens for the profit amount during the life of the arrangement in the fixed interest method.
- In conventional loans, with this field set to Yes, the system allows the user to pay more than the accrued interest and stores the excess accrual amount in the Total Repay Amount (TOT.RPY.AMT) field in AA.INTEREST.ACCRUALS.
This is possible for all payment types excluding the ones based on transaction amount and routines.

During the reversal of an Apply Payment Activity, the system creates an imbalance in AASUSPENSE. This imbalance can be offset and cleared off using the activity, which is in the format of <<PL>>-ADJUST.SUSP.BALANCE-BALANCE.MAINTENANCE.

The application is used to define the rule for how payment should be split among the Bills or Properties. This is used in Payment Rule Product Condition which also defines the order of repayment.
Field |
Description |
---|---|
PAYMENT.RULE.TYPE |
It specifies how the payment rules apply to an arrangement |
Current |
Payment is applied on arrangement's current balances. (For Example, current principal, accrued interest, etc.). This settles the current balances and doesn’t look at application order. Input to application order is not allowed for Current Balance repayments. |
Bill Property |
For product with bills and due amounts, payment to the due amounts is Property wise(For example, all Principal amounts followed by all Interest amounts, etc.) |
Bill Date |
For product with bills and due amounts, payment to the due amounts is bill Date wise (For Example, all amount on bill 1 followed by all amounts of bill 2, etc.). |
Pay In Advance |
It indicates that the amount should go into the UNC balance. |
Advance |
The advance payment amount settles the accrued interest till date (if Settle Unearned Interest is not set), loan principal and charges, periodic charges of Defer type . During this settlement, the system raises future bills in advance and apportions the payment. The bill status moves to:
The Advance option should be set only for the Payment Bill types and valid only for the DUE Payment method.
This Advance option is available for all payment types excluding the payment types based on transaction amount and routines. |
Advance Settle Date |
When this field is set to as DUE, the advance payment parks the funds in the ADV<ACCOUNT> balance type from the payment date till the actual bill due date and settles the bills. This option enables forward value dated apply payment activity to be triggered and the bill settlement to be effective on the actual due date of the bill. On the due date, the system settles the due balance of principal and interest or moves the funds to unallocated credit based on the Advance Payment rule type setup.
This field is applicable only for conventional loans configured with the ADVANCE payment rule type and is not applicable for upfront profit contracts.
Advance Settle Date is a no-change field, so once it is authorised the value in the field cannot be modified later.
|
Fwd Bill Settle |
When this field is set to YES, allows this payment rule type to apply payment to the bills that are generated in advance using early repayment options. Only when this field is set to yes, the bills are settled from ageing perspective. This controls whether the payment should be considered for delinquency when no outstanding bills exist. If enabled along with Bill Total option in Overdue condition, any repayments when no outstanding bills exist are stored in the AA.ACTIVITY.BALANCES file. During subsequent make due of bills, this amount is considered while updating the Delinquency outstanding amount. |
Tax Inclusive
|
The system can be configured to calculate the tax on accrued interest (both principal interest and penalty interest) at the time of collection of that accrued interest when the Tax Inclusive field is set as Yes in the corresponding Payment Rule Type used for the payment. |
Make Due
|
When this field set as Yes in the Payment Rule Type it includes the accrued interest and its corresponding tax collected in the loan statement. If Tax Inclusive is set to Yes, then Make Due should also be set as Yes. Else, the system raises an error when the Payment Rule Type is committed.
|
Add Payment Rules Property to Existing Arrangements
The financial institutions can add the Payment Rules property to the existing arrangements of the Accounts, Deposits, and Lending product lines using the Add New Property, New Prop Avl, and New Prop Avl Date fields in AA.PRODUCT.MANAGER.
Though the Payment Rules property is a mandatory property in the Deposits and Lending products, the Payment Rules property is supported by the Add New Property feature, being a multiple type property. So, a new Payment Rules property can be added to the Deposits and Lending products and added to the existing arrangements.
Read Add New Property for more information on the configuration.
Periodic Attribute Classes
The table below lists the Periodic Attribute Classes that define an overpayment limit amount for a loan or calculate the overpayment limit amount based on the total loan amount or the outstanding loan amount.
Periodic Attribute Class |
Description |
---|---|
ADHOC.PREPAY.CURRENT |
Calculates lumpsum overpayment limit amount as a percentage of outstanding loan amount. |
ADHOC.PREPAY.TOTAL |
Calculates lumpsum overpayment limit amount as a percentage of total loan amount. |
ADHOC.PREPAY.VALUE |
Defines lumpsum overpayment limit as a fixed amount. |
REGULAR.PREPAY.CURRENT |
Calculates regular overpayment limit amount as a percentage of outstanding loan amount. |
REGULAR.PREPAY.TOTAL |
Calculates regular overpayment limit amount as a percentage of total loan amount. |
REGULAR.PREPAY.VALUE |
Defines the regular overpayment limit as a fixed amount. |
Actions
Individual AA.PROPERTY.CLASS.ACTION records control which Product Line it’s associated with.The Payment Rules Property Class performs the following Actions:
Action Name | Description |
---|---|
ALLOCATE | To define method by which a single payment is applied to multiple bills and multiple amount types. |
CREATE.DUE | To raise due bills for the outstanding and overdue. |
PRE.BILL | Prepayment towards future bills along with the un-accrued portion will be catered by using the field SETTLE.UNEARNED.INTEREST in AA.PAYMENT.RULE.TYPE. This field, when selected, allows settlement of un-accrued interest and accounting are similar to the case prepayment of balances |
UPDATE | The update action is initiated manually and allows the User to change any of the PAYMENT.RULES attributes. This action can be initiated as part of the NEW-ARRANGEMENT and UPDATE- PAYMENT.RULES activities. |
Accounting Events
The Payment Rules Property Class does not perform any Actions that generate accounting events.
Limits Interaction
The Payment Rules Property Class does not perform any Actions that impact on the limits system.
In this topic