Configuring Scheduling Payments

The following section describes the configuration required for scheduling payments.

Scheduling Payments

The Payment Schedule Property Class is used to schedule the payments for a loan arrangement. The user can input Payment Schedule values. Payment Type is a mandatory information and can be created by users. The available Payment Types are stored in AA.PAYMENT.TYPE table, which can be accessed through the AA Product Builder. Some of the payment types supported by AA are listed below:

• Constant: This results in constant repayments, that is, the principal and interest repayment are constant. It is used for Annuity arrangements. It requires both account and interest properties to be specified in the Payment Schedule Property Class. The Charge Property can be optionally added.
• Linear: Here, the principal repayment remains fixed over the lifetime of the arrangement. Optional properties such as Interest, Charge and Tax may be included. The actual amounts calculated by these properties are added to the fixed principal amount repayment.
• Actual: When the Type is Manual, then the allowed Calculation Type is Actual, in which case, the user has to specify an amount in the arrangement for the Payment Type. When the Type is Calculated, Actual is normally used for repayment of the calculated property classes (for example, Interest, Charge and Tax) and the amount is determined on each payment schedule date. It can also be used in conjunction with the Account Property Class, such as, Principal, when a percentage need to be specified in the Payment Schedule Property Class.
• Transaction: This makes use of the disbursement transaction amount and capped charges linked with the activity as the source to calculate the payment amount.
• Percentage: In this calculation type, the repayment is linearly distributed for the percentage defined over the period. This is allowed for both Principal and Interest properties together for blended payments and just the Account property for Principal only payments.
• Fixed Equal Repayment: Payment Type Fixed Equal defines a manual repayment amount for the loan. As the name indicates, it is a fixed repayment amount given by the user. In addition it is also possible to specify the component that has to be fully invoiced which could supersede the fixed equal repayment amount defined by the user. Please refer to scheduling payment types
• Progressive: On choosing this type, a progressive percentage should be defined in the Prog Pay Perc field . The system calculates an amount which is progressing by the rate specified in Prog Pay Perc. Exactly same as CONSTANT type when Prog Pay Perc is defined as 0. Optionally user routine could be attached for this type.
• Other: It is a user routine attached to the Calculation Routine field.
  
• Rule 78 Routine based calculation: The lending arrangement can have payment schedules built on Rule 78 calculation. A Routine based Payment Type can be used to achieve this. The Cal Routine in those payment types should use the AA.CALCULATE.RULE78.PRIN.AMOUNT and AA.CALCULATE.RULE78.INTEREST.AMOUNT routines to build the principal and interest schedules respectively.

  

  

  Read Rule78 payment setup for more information.

• Payment Method: Once the Payment Type has been specified, the user can specify whether the amount is Due (to or from the customer), Pay (for rebates and automatic scheduled disbursement) or Capitalised.Interest only bills of loans can be capitalised to the principal for Islamic finance contracts and conventional loans.
• Max Percentage: Restricts the percentage definition in Percentage attribute in Payment Schedule product conditions. The repayment percentage of original loan principal definition is restricted to maximum of percentage defined in this attribute. Amortisation Schedule always covers 100% of total granted loan amount but the calculation percentage is based on the maximum percentage defined.

Payment Schedule conditions can be pre-constructed through AA.PAYMENT.TYPE and default values can be assigned to Payment Schedule conditions during the arrangement creation using an API validation.

Read AA.PAYMENT.TYPE in Payment Schedule property class for further details.

If a specific amount needs to be collected on the final schedule date, that amount may be stated in Residual Amount field of the Payment Schedule production condition. The amount stated in this field is exclusive of any scheduled calculated amount on the final schedule and is always considered to be belonging to ACCOUNT property.

If a specific amount (residual amount) needs to be collected at the maturity date of the term, it can be achieved by either defining the residual amount or by defining an amortisation term in the Amortisation Term field.

The Payment Mode field can be set to ADVANCE for payment of advance interest. The Interest Property Class is mandatory and it is possible to input in this payment mode setup.

• Payment Freq field - indicates the frequency at which payments are made due.
• Start Date field - indicates the actual payment start date. If the start date is mentioned, then the payment frequency is applied on the start date. Else, the system defaults it from the base date. Ad-hoc payment dates can be defined by expanding the multi-value sets and defining the dates in the Start Date field. Payment and Due Frequency fields have to be null. Additionally, an End Date or Number of Payments can be specified to indicate when the payments should terminate.
• End Date field - indicates the actual payment end date.
• Either an End Date or Number of Payments can be specified to indicate when the payments should be terminated.

Issue Bill In Advance

Bills can be issued in advance by setting the In Adv (BILL.PRODUCED) field in the Payment Schedule product condition for all payment types.

On the bill issue date, the system considers any forward-dated changes between the issue bill and payment dates to schedule and calculate the bill amount for the current period. However, any forward-dated change between the issue bill and payment dates that is input after the bill is issued, is effective only from the next payment date.

Bills issued in advance are treated as current bills and can be settled in advance irrespective of the Advance Payment Restriction field defined in Payment Rules Condition.

For a Periodic Charge, bills can be issued in advance only when the Property Type is set as Defer. If the Periodic Charge is not set to defer, the system raises an override to indicate that the bills can be issued in advance only for Defer type of periodic charges.

The assessment period for the Defer type of periodic charges are from previous issue bill to current issue bill date. The system triggers LENDING-ISSUEBILL-PERIODIC.CHARGES*<PAYMENT.TYPE> in accordance to the value defined in In Adv (BILL.PRODUCED) field in Payment Schedule condition.

• The bill generated on the advance date includes all the deferred charges from previous issue bill date to the current issue bill date.
  • Periodic Charges of Defer type should include all the deferred charges only.
  • Other features like activity-based charges with free counts are not possible in Defer type of periodic charges.
• Any charge raised after the current issue bill date is included in the next assessment period and in the next billing cycle.
• The periodic charges are be made due on the payment date and can be repaid thereafter.

During an advance payment between the issue bill date and the payment date, the payment is appropriated against periodic charges based on the Payment Rules condition. Advance repayments of loan installment is possible for all payment types excluding the payment types based on transaction amount and routines.

For a product with Periodic Charges set to Defer and with issue bill in advance, the system validates if the Periodic Charges property is found in the advance payment rule configured for the product. If it is missing, then the system raises a validation error (at proofing or arrangement level).

The order repayment should be: Periodic Charges, Charges, Interest and then the Principal.

In the example given below, the AGEINGFEE and DISBURSEMENTFEE activity charges are set to Defer Application Method .

These two charges are collected using a PCDEFER periodic charge property which is set to Defer property type . Therefore, this PCDEFER property can be set to generate bills in advance.

The periodic charge property which is set to Defer property type should have its corresponding product condition as follows:

The Payment Schedule should have bills issued in advance for the PCDEFER Property.

Extend Cycle

Periodic charges, interest and scheduled charges can be extended and collected beyond the loan maturity date or the loan payment end date by setting the Extend Cycle field to the corresponding property class for the payment type.

In the example given below, the EXTENDPC Payment type has Extend Cycle field set to PERIODIC.CHARGES.

The EXTENDPC payment type has the Extend Cycle field set to PERIODIC.CHARGES. Thus, the AGEINGFEE which is charged after the loan maturity or the loan payment end date can be extended and collected as a part of the PCDEFER periodic charge property as Extend Cycle is set.

The PCDEFER periodic charge is set to be made-due every month with the bill to be issued 10 days in advance.

Thus, the system can be configured for:

• Only a Periodic Charge with Defer property type
• Only a Payment Type which has Extend Cycle set
• A Periodic Charge with Defer property type and a payment type with Extend Cycle set to collect the deferred charge.
  • The system raises an error if the loan’s maturity date has a defer type periodic charge’s due date (bill issued and made due on the maturity date) indicating Payment Type is not set as Extend Cycle. Thus it ensures that all deferred charges are made due till the loan is closed.

Read the Payment Schedule Property Class user guide for more information on other options available for setting up schedules.

Minimum Payment Amount

A minimum payment amount is required to be defined by some financial markets. AA supports to capture a minimum payment amount based on the bill type. This gives the flexibility for the users to group properties by bill type and assign a minimum payment amount for them.

• It is possible to setup minimum payment amount based on the bill type – Note that it is applicable only if Account Property and on Actual Payment Type.
• The Group Min Property field is a part of the Minimum Payment set of fields to capture the Minimum Invoice Component (MIC). This field is mutually exclusive with Group Min Amount.
• Bill Type wtise MIC can be defined using the Group Bill Type and Group Min Property set of fields.

In the Group Bill Type field, only Payment type records are allowed.

The Minimum Payment Type field is applicable only when the payment type for Account Property displays the CalculationType field set to Actual and the Type field set to Calculated.

• If the calculated payment amount for the given bill type is less than the minimum payment amount, then the bill is raised of the minimum payment amount. The difference is billed as principal (Account Property).
• This is allowed only for scheduled payments and not for Activity-based charges or break rule charges.
• Minimum payment amount calculation can be considered during payment schedule projections and during simulations.
• The following attributes indicate the minimum amount for an arrangement.
  • Group Bill Type field - indicates the bill type for which the minimum amount has to be applied.
  • Group Min Amount field - indicates the minimum bill amount.
• On the scheduled payment date, when a bill is raised for the bill type mentioned in the Group Bill Type field, the system evaluates the calculated payment amount against the minimum amount specified.
  • When the calculated amount is greater than or equal to the minimum amount, then the calculated amount is billed.
  • When the calculated amount is lesser than the minimum amount, then the minimum amount is billed. The differential amount is billed as Account (Property).
• Minimum payment amount can be applied only to Actual payment types and does not apply for Constant, Linear or Progressive payment types.

When the bills are set to combine, the system raises a consolidated bill for all payment type lines that has a scheduled bill getting due on the same date.

BT.MINIMUM.AMOUNT is considered only when the Account Property is part of the combined bill.

• If the Account Property is not available, then the calculated property amounts are billed at actuals.
• If the Account Property is available, the system checks if the sum of the calculated amount per property (including Account) is greater than or equal to the minimum amount.
• If there is a short fall, the difference amount is increased in the Account Property to match the minimum amount specified.

When the bills are not set to combine, the system raises separate bills for each payment type. When there is at least one bill for an Account Property, the system compares the calculated amount of all bills scheduled for the date sharing the same bill type to see if it is greater than or equal to the minimum amount specified.

If the condition satisfies, the system issues the bill for the calculated amount. If the condition fails, the system issues the bill for the minimum amount specified.

When the system tries to adjust the account portion of the bill to match the minimum payment amount and the adjustment amount is more than what is outstanding in the CURACCOUNT, then the system restricts the adjustment to what is available in the CURACCOUNT.

Fixed Equal Repayment

• Arrangement loans can generate the Fixed Equal Repayment (FEP) Schedule.
• AA.PAYMENT.TYPE - FIXED.EQUAL is used in loan arrangements to indicate an FEP schedule. This payment type displays the Calculation Type field as manual. The mandatory Property Classes are Account (Principal) and Interest.
• The user can manually input the repayment amount during arrangement creation in the Actual Amount attribute in the Payment Schedule. The schedule projection is based on this user input FEP amount.
  The value in the Term field is optional for this Payment Type.
• When the Term field is not captured, it is calculated based on the FEP amount given by the user.

Zero Payments

Regular payment can be skipped completely once or for a regular period. Remaining payments adjust the skipped installment. Zero payment can be done either by skipping the month(s) in Pay Freq field or by giving only start and end date and skipping the interim payment(s).

Progressive Payments

The PROGRESSIVE payment type is used to increase the repayment amount by a pre-defined frequency captured in the Pay Freq field.

• When the Pay Freq attribute is 0%, the system behaves like an Annuity contract. If it has a percentage defined for example 2%, it means, the repayment amount increases by 2% for every repayment and the entire principal is settled on the payment end date.
• The Prog Pay Perc attribute in the Payment Schedule component accepts the progressive rate at which the repayment amount can be incremented for every repayment

Future Dated Conditions

The user can introduce a new date at the arrangement level using the FORWARD.DATED value in the Type attribute in the AA.PROPERTY.CLASS record. Once captured with a future date, the system automatically schedules this, and during close of business, the scheduled activity is processed applying the new condition to the Arrangement.

Payments Linked with Disbursement

• The consumer loan business segment would require a down payment (of principal) along with each disbursement. This is calculated as percentage of the net movement on CUR balance.
• Such a payment calculation requires the following information
  • The disbursement event, in order to configure a payment calculation whenever a disbursement event occurs.
  • The source on which the (down) payment has to be calculated.
  • Optionally, a configuration to generate the bill online.
• DISBURSEMENT, is a relative date option that is used to identify the disbursement event and triggers a payment calculation. This should be specified in the Start Date field.
• Payment type with Calc Type as TRANSACTION is to calculate the payment based on net movement.
• Schedule Type has to be set as ONLINE, if the bill has to be generated online along with the disbursement.

For instance, if there is a disbursement of 1000, with a charge of 200 (set to cap) that is linked, the payment amount can be defined as a % of 1200. If the % is defined as 25%, then the system calculates a payment of 300. The condition is shown below.

Special Payments

Special payment is the actual amount specified by the user to substitute the regular instalment amount for the specific period, either single or regular. This amount should be specified in the Actual Amt attribute.

For example, the instalment amount needs to be different (user defined) for every March and the system calculates the value in the Calc Amount field for the remaining instalments by considering the specific payment for the given instalment(s).

Deferred Payments

The Defer Period attribute in the Payment Schedule Property Class is used to define the duration the scheduled payment should be deferred from the original cycled date.

When a value is defined in the Defer Period attribute, then the system schedules DEFER.MAKEDUE or DEFER.CAPITALISE activities on the cycled date and moves the bills to DEFER status.

On the cycled date + Defer Period, the system schedules MAKEDUE or CAPITALISE activities where the bills are be moved out from the DEFER status to their respective status.

Calculation of Annual Percentage Rate

Read the Annual Percentage Rate section in the Reporting Property Class user guide for more information on Annual Percentage Rate (APR) calculation.

Installment Amount for Multiple Disbursement

The Include Future Disb (INCLUDE.PRIN.AMOUNTS) attribute in Payment Schedule specifies the option for calculating the EMI considering the future installments.

When left blank, the default behavior continues. For a loan with multiple disbursements, the installment amount is calculated on the first disbursement and on further disbursement the user has to configure the system to recalculate the Term or Payment amount using On Activity, Recalculate fields. Else, the system lets the future disbursements get adjusted to repay in the final installment on the maturity date.

When the Include Future Disb field is set to Yes, the system calculates the constant installments with interest on outstanding principal and future disbursements or payments scheduled. This facility is applicable for all payment types. This feature is also applicable for fixed profit contracts.

Full or Partial Capitalisation of Interest/Profit

This section describes the full or partial capitalisation of interest and profit accruals in detail.