| Bookmark Name | Actions |
|---|
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
- 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.
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 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 currently applicable only for Fixed Interest Method where the total profit amount for the arrangement is known. System ensures that accrual happens for the profit amount during the life of the arrangement for Fixed Interest method.
The functionality is not applicable for conventional type of Interest as there is a possibility in the conventional type that the source balance can become zero enabling a mismatch between the accrual and collected interest amount.
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 |
If chosen, the payment amount is applied only on the current balances of Interest, Account Properties and advance due balances for the Charge Properties. During this settlement, System raises future bills in advance and these bills are either in "SETTLED" or "ADVANCED" status. Advance field should be set only for the "Payment" Bill types and valid only for the "DUE" Payment method. Valid for future schedules if the Properties belong to the system calculated payment types CONSTANT, PROGRESSIVE and ACTUAL or OTHER (any charges). Also valid for any bills in Issued status(even for LINEAR or INTEREST.ONLY type). Otherwise, the definition is void and the repayment amount is passed to the remainder Activity. |
|
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. |
Periodic Attribute Classes
The Payment .Rules Property Class is not associated with any Periodic Attribute Class.
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.
Add Bookmark
save your best linksView Bookmarks
Visit your best linksIn this topic
Are you sure you want to log-off?