AALendingAdvancedPart2 PDF

AA Lending Advanced - Part 2
Temenos University - November 2012 1


PAYMENT.SCHEDULE is a mandatory Property Class of LENDING Product Line.

It is used to specify the frequencies and other attributes for various Properties like
Principal, Interest, Charges, etc.

Each Lending T24 product will mandatorily have a single PAYMENT SCHEDULE Property
defined, and its Product Condition is Currency dependent.
The AA payment schedules have various flexible and useful features. During an activity, if
permitted, user can amend or delete any of the future conditions.
In a Payment Schedule, user can define payment schedule which will have options Due
and Capitalise payment type. For example, the bank may collect Interest, Principal from
the customer, say, on a Monthly basis, this would be due from the customer.

PAYMENT.TYPE Field denotes different types of calculated payments that could be

applied. This field is Mandatory. Should be a valid record in AA.PAYMENT.TYPE File. T24
supports four types of calculated payments:
• Constant – results in equal repayments. This is used for ‘Annuity’ arrangements and
requires both an Account and Interest property to be specified.
• Linear – Term Amount repayment remains fixed over the life of the arrangement.
Optional properties such as Interest, Charge, and Tax may be included. The actual
amounts calculated by these properties will be added to the fixed Term Amount
repayment.
• Actual – is used for repayment of calculated property classes (i.e. Interest, Charge, and
Tax) and will be determined on each payment schedule date.
• Other – user defined
• Progressive – PROGRESSIVE is used to increase the repayment amount by a pre-
defined frequency captured in PAYMNET.FREQ and predefined rate specified in
PROG.PAY.PERCENTAGE . When the field PROG.PAY.PERCENTAGE is 0%, the system
will exactly behave as Annuity contract. If it has a percentage defined for example 2%,
it means, the repayment amount will increase by 2%.
PAYMENT.METHOD : Once the Payment Type has been specified, the user can specify
whether the amount will be Due (to or from the customer) or Capitalised.

CONSTANT - Instalment in fixed or equated amounts is called Constant or Annuity type.

Instalment amount is same throughout. In this case, the Principal and Interest
components vary in each instalment.

In this example, we can view the Constant payment Schedule set up in the Product
conditions and View the Constant payment schedule in the Arrangement

Linear Type -Principal Instalment is same throughout, but interest component will be
gradually coming down. Hence the total amount of repayment will be gradually coming
down.

In this example, we can view the Payment schedule Product conditions with Linear
payment type and the Linear Payment Schedule in the Arrangement.

Progressive Payment Type - In this example we can view the Product conditions set up
with Payment type Progressive and the Progressive payment schedule in the
Arrangement.

PAYMENT.METHOD : Once the Payment Type has been specified, the user can specify
whether the amount will be Due (to or from the customer) or Capitalised.
It is possible to define a RESIDUAL.AMOUNT at the maturity date of a term product to be
paid on the last payment date of the arrangement. This can be specified by entering an
AMORTISATION.TERM with which T24 can calculate payments and any residual or by
entering a RESIDUAL.AMOUNT directly.
RESIDUAL.AMOUNT is available in product condition (not in MB version). This field can
be used at arrangement level to input the Residual amount.

In this example, we are going to see about the Amortisation Term in the payment
schedule.

In this example, the actual payment amount is calculated based on the amortisation
term and not on the actual term defined in TERM.AMOUNT property of the
arrangement. This calculated payment is then spread across actual term of the
arrangement. If the amortisation term is greater than the actual term then we would be
left with residual amount at the maturity date. ,


In this example, the actual residual amount 2000 is defined in the field
RESIDUAL.AMOUNT. Any residual amount must then be paid by the client on maturity of
the arrangement

PAYMENT.FREQ field indicates frequency at which payments will be made due.

Example:
a) M 01 31. M = Monthly. 01 = one monthly intervals. 31 = the last day of the month, b)
M 03 31 M = Monthly. 03 = three monthly intervals. 31 = the last day of the month. c) M
01 10 M=Monthly, 01 = at monthly intervals10 = 10th of the month, d) 31 MAR 2006 W ,
where W= weekly. In this case, the first schedule would fall on 31March 2006, e) 31 Mar
2006 BSNSS, where BSNSS = every business day. In this case, the first schedule would fall
on 31March 2006.
DUE.FREQ Field indicates actual frequency when payment needs to be made due. Due
frequency is defined for each payment property under a payment type. Payment
frequency is defaulted when due frequency is null. Generally both payment and due
frequency has same value.

START.DATE - This field indicates the actual payment start date. If Start date is mentioned
then the payment frequency is applied on the start date. Else, it is defaulted from the
Base Date. Adhoc payment dates can be defined by expanding the multivalue sets and
defining the dates in the field START.DATE. Payment and Due Frequency needs to be null.
Additionally an End Date or Number of Payments can be specified to indicate to T24
when the payments should terminate.
END.DATE - This field indicates the actual payment end date.
We know that either an End Date or Number of Payments can be specified to indicate to
T24 when the payments should terminate.
NUM.PAYMENTS field- If a frequency has been specified the user can specify either an
End Date or Number of Payments to indicate to T24 when the payments should
terminate.
Both START.DATE and END.DATE fields can accept not only an absolute date but also a
‘relative’ date.

The values START, MATURITY and RENEWAL events can be specified with Relative date,
which can relate to past or future event that will take place. The user can define a
relative date in the field START.DATE or END.DATE based on events which are:
START – First Disbursement, MATURITY – Maturity of an arrangement, RENEWAL –
Renewal date for an arrangement
Input into the fields START.DATE and END.DATE has to be done at the arrangement level,
in any one of the following manner.
R_XXXX + 2D - (Relative event XXX and offset by 2 Calendar days forward)
R_XXXX - 5Y - (Relative event XXX and offset by 5 Years backward)
D_20001130 - ( Exact date specified as 30th Nov 2000)
20001130, 30 NOV 2010 etc. (Standard date field)
For example R_START+5D could indicate that the calculation and repayment start date of
the loan is from 5 days of the First disbursement of the arrangement. R_RENEWAL could
be linked to a scheduled charge which is payable every time the arrangement is
renewed.

In this example, we are creating an arrangement with repayment schedule to start 1

month after disbursement by specifying R_START+1M that is repayment to start after
one month from disbursement date.

You may need to revise your repayment schedule when loan amount, or interest rate or
term changes. You can specify which activity should result in recalculation of repayment
schedule.
ON.ACTIVITY Field to state a list of activities during which payment schedule is to be
recalculated. When those activities are performed, system would automatically
recalculate the payment schedule. For example, the following Activity Classes may
require a recalculation:
For a scheduled recalculation RECALC.FREQUENCY Field must be defined at weekly,
monthly, yearly frequency etc. If RECALCULATE Field has recalculation type as ‘nothing’
for any of the activities, automatic recalculation to be scheduled for this.

UPDATE – CHARGE, CHANGE – INTEREST, CHANGE– PAYMENT.SCHEDULE, CHANGE.TERM

– TERM.AMOUNT, INCREASE – TERM.AMOUNT, DECREASE -TERM.AMOUNT. For each of
these activities, the resulting recalculation types must be specified in the associated field
- RECALCULATE.
More than one activity may be stated for recalculation. But there should be no
duplication. Should be a valid entry in AA.ACTIVITY file.
BILL.TYPE Field can accept values – Payment & Expected.

Recalculate field indicates which payment parameter to change when changes occur to
payment schedule or when any specific activity is triggered on the arrangement. The
recalculation types are:
Payment – the payment amount will be changed.
Term – the term of the arrangement will be altered.
Residual – the residual amount will be changed.
Nothing – the payments, term, and residual will be unchanged. In this case a
recalculation frequency should be specified. If "Nothing" is selected, a recalculation
frequency should be specified.
Progressive Payment – Increase /Decrease in CALC.AMOUNT based on the Progressive
Pay Percentage.

When more than one payment falls due on the same date, user can opt for combining
the bills. For example, user can combine interest bill and charges bill, which have the
same frequency and fall on the same date.
Bills that are issued on the same date and will also become due on the same date are
typically combined into a single bill.
This bill will then contain the various components of the payment. This provides for
example, the ability to combine a monthly “annuity” loan repayment with a monthly
charge to provide the user with a single bill amount.
BILLS.COMBINED Field is used to exercise this option of combining bills falling on same
date.
This Bill record is also the basis of the AA Overdue processing, the details of which you
will learn later.
Bills contain details of different balances due, due date.
Payment of billed amount by due date is considered up to date.
Bills outstanding after due date is the basis for overdue processing.

In AA, Payment Schedules generate Bills when a scheduled amount is not capitalised and
made due. Unlike other T24 contract applications, when a scheduled amount is made
due, processing will not happen automatically. It has to be processed outside AA. Bills
for a payment, can be generated on the due date or by specified number of days in
advance by indicating number of advance days in BILL.PRODUCED field–E.g. if interest is
to be made due to customer on the 10th of every month and bill is to be issued on the
9th (previous working day), this field should be set as 1.
Bills which are due are stored in AA.BILL.DETAILS table. The bill will contain the details
of the amounts due, the due date, etc.
When payment frequency for a Bill, defined in the product condition is changed, a bill
already made due in the arrangement for a future date, remains unchanged.
All balances, whether principal, interest or charges, when they become due are billed.
Bills are automatically issued and made due during COB (Close of Business) according to
the schedule. A chaser fee charge can be linked to the Issue Bill Activity.
PERCENTAGE Field allows the user to define a percentage that would be applied on the
outstanding balances and made due. Only the percentage of the amount would be
issued in the bill and Made due. The remaining amount would remain on their
respective balances and any further calculation would be based on this balance. Would
only be allowed for ACCOUNT and INTEREST properties. The payment type should
belong to CALCULATED type with the CALC.TYPE set as ACTUAL. Should be in the range
of 0 to 100.
Different payment types can be specified for different periods.

While the above, except last 2 were available till R9, the following are possible from R
10.
Regular additional payment - A regular additional payment means that an additional
payment amount is specified on a recurring basis, e.g. annually. This amount applies
over and above the regular instalment amount.
Regular special payment - A regular special payment means that an actual payment
amount is specified for a regular instalment. This amount replaces the regular instalment
amount.
The additional amount will be paid over and above the normal loan instalment. When an
additional amount is set in a repayment schedule, the remaining instalments are
automatically calculated by the system.
These payments could be in the middle of an annuity schedule, or an SLA (Single Line
Amortisation) schedule (equivalent to Linear in T24). When the payments are added to
such a schedule, the payment amount is calculated to take into account the additional
payment(s).

One off Additional Payment – The customer has to make a constant repayment
of USD 5,000 each month. For the month of September alone, he pays an
additional constant repayment of USD 5,000 which makes it a total repayment of
USD 10,000 for September.
One off Special Payment – The customer has to make a constant repayment of
USD 5,000 each month. In the interim, he gets bonus pay and makes a one off
special repayment of USD 50,000 to reduce his loan burden.

In this example we are setting up an arrangement where the customer is going to pay
one Principal payment additionally along with his regular payment.

An additional Principal payment of USD 4166.67 is paid along with the regular Principal
payment as per the Arrangement condition set up.

Regular payment can be skipped completely once or for a regular period. Remaining
payments will adjust the skipped instalment. Zero payment can be done either by
skipping the month(s) in PAYMENT.FREQ or by giving END.DATE / START.DATE skipping
interim payment(s).
In either case, system will calculate the CALC.AMOUNT after considering the skipped
instalments (zero payments). For an annuity arrangement having a payment term of one
year, if two regular payments are skipped in the middle of the payment period, system
will calculate the payment amount for the remaining 10 payments considering the two
zero payments and calculation logic will equate the payment amount for the
arrangement.

In this example, payments are skipped on 6th, 7th, 9th and 11th month. However, system
projects the schedule for the arrangement by adjusting the skipped installment amounts
for the rest of the payment period using its calculation logic.

It is possible to include regular and ad-hoc (recurring and non-recurring) additional

scheduled payments in the PAYMENT.SCHEDULE Property. Additional payment is defined
as the payment scheduled over and above the regular payments. Additional payments
can be given by adding a payment type and it can be either ad-hoc (single) or regular and
the amount should be specified in the field ACTUAL.AMT. The system will calculate the
CALC.AMOUNT taking into account the additional payment(s) specified.
Special payment is the actual amount specified by the user to substitute the regular
installment amount for the specific period, either single or regular. This amount should
be specified in the field ACTUAL.AMT.
For example, it is possible to say that the installment amount for March every year will
be different (user defined) and the system will calculate the CALC.AMOUNT for the
remaining installments by considering the specific payment for the given installment(s).

While you input Payment Schedule values, Payment Type is mandatory information.
Payment Types are stored in AA.PAYMENT.TYPE, which can be accessed through the AA
Product Builder. The Payment Types can be created by Users. In Payment Type, AA
supports one of the four calculation types:
CONSTANT: This will be result in constant repayments i.e. Principal plus Interest
repayment will be constant. This will be used for Annuity arrangements. This will require
both an Account and Interest property to be specified in the Payment Schedule. Charge
property can be optionally added
LINEAR: Here, Principal repayment will remain fixed over lifetime of the Arrangement.
Optional properties such as Interest, Charge and Tax may be included. The actual
amounts calculated by these properties will be added to the fixed principal amount
repayment.
ACTUAL: When TYPE is Manual, then only allowed Calculation Type is ACTUAL, in which
case User has to specify in the Arrangement for the Payment Type an Amount. When the
type is Calculated, Actual is normally used for repayment of calculated property classes
(i.e. Interest, Charge, and Tax) and the amount will be determined on each payment
schedule date. It can be also used in conjunction with Account Property Class i.e.
Principal, when a percentage need to be specified in Payment Schedule.
OTHER is a user routine attached to the CALCULATION.ROUTINE Field .

The default start date for a Payment Schedule is the Arrangement Date, i.e. Effective
Date of the Arrangement. This start date can be changed by the User in an Arrangement,
subject to negotiation conditions.
It is possible that a Payment Schedule’s last date falls before or after the Maturity Date
unlike other T24 contract based loans, where the last payment is always the Maturity
Date. For example, here for an Arrangement with a start date on Nov 24th , 6 months
term with a monthly repayment, the first repayment date has been set to 10th December
by the User, instead of December 24th. In this case, the final repayment date will be
calculated by T24 as May 10th and not the Maturity Date which is May 24th.

Certain Activities have an impact on the Payment Schedules.

We need to configure which Activities cause an automatic recalculation.
We can also configure which Activities need a recalculation on a regular basis.

Keeping the payments in the credit balance of an Arrangement may occur because of
two events.
When the loan is overpaid than the outstanding, the excess will be retained in Credit
Balance.
Secondly, when a due is overpaid, the excess payment will be temporarily retained in the
credit balance.
Keeping the payments in the credit balance of an Arrangement may occur when the loan
is overpaid i.e. Paid over and above
outstandings. Excess will be parked in Credit Balance. You may also keep advance
payments received for adjusting future dues.

When a due is overpaid, the excess payment will be temporarily retained in the credit
balance. APPLY.PAYMENT Field is used to specify the Activity to be triggered for adjusting
the credit balance, if any.
When an arrangement reaches the PAYMENT.END.DATE, all current balances except
commitment outstanding amount will be made due.

Create a Payment Schedule Product condition for Interest only monthly due with the
following Settings:
Interest only loan monthly due
Payment Amount to be recalculated every quarter
Credit balances, if any to trigger LENDING-SETTLE-PR.REPAYMENT Activity
Attributes are negotiable

In this workshop, we will see how to create a Payment Schedule Product condition for
Interest only monthly due.
Set the following conditions:
Interest only loan monthly due
Payment Amount to be recalculated every quarter
Credit balances, if any to trigger LENDING-SETTLE-PR.REPAYMENT Activity

Create a Product condition for Linear Payments

Linear monthly due
Single bill for Principal and Interest
Set to Recalculate PAYMENT amount on LENDING-DISBURSE-COMMITMENT and
LENDING-CHANGE.TERM-COMMITMENT activities
Set LENDING-SETTLE-PR.REPAYMENT Activity to apply payment from Credit
Balance
Commit the record

Linear Payments.
Linear monthly due
Single bill for Principal and Interest
LENDING-CHANGE.TERM-COMMITMENT activities
Balance
Commit the record

Create a Product condition for Constant Payments with the following inputs:
Constant monthly due
LENDING-CHANGE-REPAYMENT.SCHEDULE activities
Balance
Commit the record

Constant Monthly Payments.
Constant monthly due
LENDING-CHANGE-REPAYMENT.SCHEDULE activities
Balance
Commit the record

PAYMENT.RULES is a mandatory Property Class of LENDING Product Line.

The PAYMENT RULES Property Class is used to define the method by which a single
payment made to an Arrangement will be applied to multiple bills and multiple
amounts.
This Class does not depend upon currency and multiple Properties of this class can be
attached to a Product.

Payments into an arrangement is controlled by this property class. Rules for allocating
the payments to different bills, and different balances within bills and order of
adjustment are defined in PAYMENT RULES Property Class.
PAYMENT.RULES property class is used by any products which have amounts billed and
made due from the customer.

APPLICATION.TYPE Field is used to specify how the payment rules will apply to an
arrangement.
Bill Property: For product with bills and due amounts, payment to due amounts will be
Property wise (e.g. all Principal amounts followed by all Interest amounts, etc.)

In this example, there are 2 Bills outstanding, and Payment Rule is set as Bill Property
and with oldest first.
Further, the Property Sequence is specified as Principal, Principal Interest and
Maintenance Fee.
You can see that the Principal due is first settled across all bills, then Principal Interest
due and then Maintenance Fee due.
Finally, the remainder is processed by the Remainder Activity which is set to settle the
Current Principal.

Bill Date: For product with bills and due amounts, payment to due amounts will be bill
date wise (e.g., all amount on bill 1 followed by all amounts of bill 2, etc.).

In this example, there are 2 Bills outstanding, and Payment Rule is set as Bill Date and
with oldest first. Further, the Property Sequence
is specified as Principal, Principal Interest and Maintenance Fee.
You can see that the Bill dated 1 Mar is settled first and then the Bill dated 1 Apr is
settled.
Within each Bill, Principal due is first settled, then Principal Interest due, and then
Maintenance Fee due.
Finally, the remainder is processed by the Remainder Activity which is set to settle the
Current Principal.

Current: Payment will be applied on arrangement's current balances. (e.g. current

principal, accrued interest, etc.). This will settle the current balances and does not look
at application order. Input to application order will not be allowed for Current Balance
repayments.

In this Payment Rule, which can be used for an unscheduled or ad-hoc Payment, the
Application Rule is set as “Current” i.e. to settle the current balances in the order of
Principal, Principal Interest and Maintenance Fee Properties.
In this case, the Principal will be first decreased, and then accrued Principal Interest will
be settled, followed by accrued Maintenance Fee. The Remainder, if any will be will be
allocated to the “Unallocated Credit Balance” of the Arrangement.

APPLICATION.ORDER Field is used specify the order of adjusting bills and balances when
there are more bills and balances outstanding. For billed amounts, in addition to
specifying whether Properties or Dates will be given priority, the user must decide in
which order multiple bills will be processed. This field can be used to specify the order in
which multiple bills has to be processed. This field can accept:
1. Oldest First - Order of processing will start from first bill.
2. Oldest Last - Order of processing will start from last bill.
If APPLICATION.TYPE is CURRENT then input is not allowed in this field.

REMAINDER.ACTIVITY Field can be 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 (i.e. an overpayment).
This is handled by specifying the Activity to be processed for the remainder of the
payment. This will be subject to any Transaction Rules. Should the transaction fail, the
remainder amount will be processed by the Default Activity specified in Accounting.
MAKE.BILL.DUE Field is used 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, users 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.

PROP.APPL.TYPE Field represents balance to be paid for defined property. The values
allowed at present are Balances and NULL.
If this field is NULL the due balance in the bill for the property is settled according to the
type defined in the field APPLICATION.TYPE.
If the value is set to BALANCES, the balances (Balance types) of the property to be
specified (e.g. current principal, accrued interest, etc). This field therefore can allow
settlement of current balances along with the due balances.

The PAYMENT RULES Property Class is used by any product which has amounts billed and
made due from the customer.
An arrangement may have several bills outstanding and each bill may be comprised of
multiple amounts like principal, principal interest, penalty, tax, charges, etc. 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 will be
applied to multiple bills and multiple amount types. The amount types include, current
charges, current interest, and current principal; due charges, due interest, and due
principal; and overdue charges, overdue interest, and overdue principal.

In a Lending Product, an ACTIVITY.MAPPING Product Condition will be attached to an

ACTIVITY.MAPPING Property.
In this Product Condition, the T24 Transaction Codes used by applications such as FT, TT
will be mapped to the Accounting Activity LENDING-APPLYPAYMENT-a PAYMENT.RULES
Property.
The PAYMENT.RULE Property specified in the ACTIVITY.MAPPING Condition, will be
attached to the Product and it will be linked to a PAYMENT.RULES Product Condition.
In the PAYMENT.RULES Product Condition, the rules to apportion payment will be
defined.
Finally, in the Product Both the Activity Mapping Condition and the Payment Rules
Condition need to be attached.
In case of Payment Rules Condition, it should be attached to a Property which is
specified in the Activity defined in the Activity Mapping condition.
The linkage is that when a T24 Transaction to apply payment to an Arrangement is input
in applications such as FT, TT with a Transaction Code as specified in the
ACTIVITY.MAPPING, it will trigger the Activity to Apply Payment associated with the
PAYMENT.RULES Property. This Property in turn will use the rules specified in the
PAYMENT.RULES Product condition to apportion the Payment to different dues and
balances.

You have seen in the Payment Schedule Section that a Payment Schedule will generate a
Bill either on the schedule date or could be set to generate a Bill even on a prior date.
An arrangement may have several bills outstanding at any point of time.
You have learnt earlier that Bills which are due on the same date can be combined as a
single Bill as per the setting in the Payment Schedule. Thus, a Bill may be comprised of
multiple amounts (Properties) like Principal, Principal interest, Penalty Interest, Tax,
Charges, etc. Please recollect that an outstanding amount is associated with a Property
of a Property Class.
For example, the Principal is associated with a Property of ACCOUNT Property Class.
Both Principal Interest and Penalty Interest are associated with two different Properties,
both of which are associated with the INTEREST Property Class.
It is also possible that a Customer could make an ad-hoc or pre-payment when no
amount is due from him/her.
When a customer makes a payment, the amount may not be sufficient to pay the entire
due amount.
PAYMENT RULES Property Class is used to define the method by which a single payment
will be applied to multiple Bills and multiple amount types i.e. Properties. It can be also
used to define how ad-hoc payments can be allocated.

Create a new Product condition for Payment Rules with the following Settings:
Pay off Bills by Property in the following order:
Properties : PRINDECREASEFEE, DISBURSEMENTFEE, NEWARRFEE,
PRINCIPALINT and ACCOUNT
Old dues to be recovered first
Allocate any Remainder to credit the current Principal (use the default
PR.PRINCIPAL.DECREASE Payment Rule Activity)
Set YES to MAKE.BILL.DUE
All Attributes are not negotiable by default

In this workshop, we are going to create a Payment Rules Product conditions.

Pay off Bills by Property in the following order:
Properties : PRINDECREASEFEE, DISBURSEMENTFEE, NEWARRFEE,
PRINCIPALINT and ACCOUNT
Old dues to be recovered first
Allocate any Remainder to credit the current Principal (use the default
PR.PRINCIPAL.DECREASE Payment Rule Activity)
Set YES to MAKE.BILL.DUE

Create a new Product Condition for the Payment Rules with the following:
Pay off current bills
CURACCOUNT – BALANCES
Allocate Remainder to credit the current Principal (use LENDING-CREDIT-
ARRANGEMENT Activity)
Set NO to MAKE.BILL.DUE.
All Attributes are not negotiable by default.

In this workshop, we are going to create a Product condition.

Set the following Conditions:
Pay off current bills
Balance Type set as CURACCOUNT
Allocate any Remainder to credit the current Principal (use LENDING-CREDIT-
ARRANGEMENT Activity)
Set NO to MAKE.BILL.DUE

The SETTLEMENT property class supports selected settlement requirements for Lending,
Deposits and Accounts arrangements. The settlement property class enables the
settlement of dues / payouts using another arrangement / T24 Account or creates
DD.ITEM by providing DD.MANDATE.REF.

SETTLEMENT Property class is DATED type.

It allows specifying a drawdown account to receive funds from or specifying a liquidation
account to pay funds to.
PAYIN.ACCOUNT & PAYOUT.ACCOUNT can either be a T24 account or an arrangement
account (either LENDING or DEPOSITS arrangement). This property class is also used to
link one or more Payment Types in AA to Direct Debit mandates. This is achieved by
linking a mandate defined in the Direct Debit (DD) module to an arrangement account
which is done through this SETTLEMENT Property.

Settlement Property allows settlement of dues / pay-outs between an arrangement and

another arrangement / T24 account.
Receive definition is based on Payment Types and related activity while Payout definition
is based on Property and related activity.

PAYIN.ACCOUNT (Receive) & PAYOUT.ACCOUNT (Pay) can either be a T24 account or an

arrangement account. Currently, pay-in settle activity and pay-out settle activity allows
APPLYPAY
Settlement property will function only if PAYIN.SETTLEMENT Field is set to YES.

The Receive Settlement Instructions are meant for funds coming into the arrangement.
The PAYMENT.TYPE Field is the link between Payment schedule and Settlement Property.
This can be sub valued for different types of Interest, Charges.
The PAYIN.SETTLE.ACTIVITY Field holds the activity that is run to receive funds, currently
APPLYPAYMENT activity alone is allowed. This settlement activity refers to the
AUTO.SETTLE Field of the respective payment schedule. If this field is set to YES, then it
will look up the Settlement property and fetch the settlement account corresponding to
the same payment type.
Please note that where there are funds available in UNC, the system would have already
settled out of it during MAKE DUE and the outstanding itself would be only the
remaining amount of the bill.
The Active fields for PAYIN.SETTLEMENT can be used with field values YES and NO to
switch off and switch on settlement instructions, without clearing other settlement
related fields. This could be to stop a settlement instruction at arrangement level or to
change the customer level settlement instruction for a payment type in the
arrangement.

Funds can be received from either a T24 ACCOUNT (Customer / Internal / Nostro) or
from a T24 Arrangement or from a DD mandate. Examples of funds received – Receipt of
Schedule Principal and Interest Payments, Charges.

All Activity Charges are grouped under the payment type ACTCHARGES. Activity Charges
looks in the Settlement Property for that payment type and fetches the corresponding
settlement instructions. The Settle Activity is defined in Activity Charges PC. This
settlement activity refers to the AUTO.SETTLE Field of the respective Activity Charges
property. If this field is set to YES, then it will look up the Settlement property and fetch
the settlement account corresponding to the same payment type.
Please note that Activity Charges property is designed to run the activity to settle out of
UNC first, only when there is remaining outstanding to be settled, it will go to the
settlement property, provided the Auto Settle field is set to YES.

During the settlement process, the account specified to settle bills may or may not have
sufficient funds for the purpose. Values FULL, PARTIAL and NONE in the PAYIN.RULE
FIELD controls the settlement process in such cases, using the ACCOUNT.DEBIT.RULE.

FULL: Irrespective of the fact, whether or not funds are available in the specified
account, system debits the Pay-In account to the extent of the bill amount. If funds are
only partially available, system creates an overdraft in the Pay-In Account provided the
PAYIN.ACCOUNT has a limit attached to it.
PARTIAL: System debits the Pay-In Account only to the extent of funds available.
NONE: If funds are not fully available to settle the bill, system would not debit the Pay-In
Account.

Arrangement bills in one currency can be settled by another arrangement / T24 account
with another currency. Settlement processing will happen when 1) source arrangement
is in local currency and settlement arrangement / account is in foreign currency, 2)
source arrangement in foreign currency and settlement arrangement / account is in local
currency, 3) both source arrangement and settlement arrangement/account are in same
foreign currency, 4) source arrangement and settlement arrangement/account are in
different foreign currencies. Further, for local currency arrangements, when due bills are
in foreign currency, settlement can take care of FCY bill settlement for the related LCY
arrangements.
During the settlement process, system calculates the exchange rate based on the
settlement arrangement.

When bills issued are to be settled directly by debiting an account in a third party bank,
it is done by linking a mandate defined in the Direct Debit (DD) module to an
arrangement account through the SETTLEMENT Property.
For the direct debit to work, the mandate should have a status of ACTIVE/AVAILABLE.
When bills are issued, DD.ITEM records will be created by the system for the payment
types that are specified in the SETTLEMENT property. APPLY.PAYMENT field in the
payment schedule property should be input with the payment rule for the direct debit.
This will result in the AA module appropriating the unallocated balance to the properties
specified for settlement. Whenever a DD claim is rejected by the correspondent Bank,
the associated repayment is reversed in AA.
When bills are issued, DD.ITEM records will be created by the system for the payment
types that are specified in the SETTLEMENT property with the contract reference as the
AA.ARRANGEMENT.ACTIVITY ID of the issue-bill activity. On the claim date (the value
date of the bill payment), the arrangement account is credited with funds. The DD.DDI
record status should be AVAILABLE to make use of the direct debit functionality to settle
the bills. In the first instance, when the DD.DDI record is created the status will be NEW
and after authorisation, the same should be changed to AVAILABLE.

Create a Settlement Product condition with the following Settings:

For Receiving Schedule Payments Interest/Charges/Principal:
Settle activity is to be defined as LENDING-APPLYPAYMENT-PR.REPAYMENT
Settlement instructions should be active
Pay-In account should be debited only to the extent of funds available

In this workshop, we are going to create a Settlement product condition with the
following settings:
For Receiving Scheduled Payments – Interest, Charges and Principal
Define Settle activity as LENDING-APPLYPAYMENT-PR.REPAYMENT
Settlement instructions should be active
Pay-In account should be debited only to the extent of funds available

OVERDUE is an optional Property Class of LENDING Product Line. The OVERDUE Property
Class is useful to do past due processing.
Using this Property Class, a Bank can create and manage its own overdue statuses (e.g.
grace, overdue, non-accrual, etc.) and it is also possible to have different rules for
overdue processing for different products.
Worst aging status for an arrangement can be indicated.

Overdue property class is DATED and TRACKING.

Overdue rule definition is based on the BILL.TYPE, so that different rules may be setup
for different bill types.
BILL.TYPE can be specified for individual Overdue Status.
BILL.TYPE being soft-coded, aging rules may also be defined based on AA.PAYMENT.TYPE
by choosing a soft BILL.TYPE in Payment Schedule.
BILL.TYPES can be used to identify the main aging rules that would determine worst
aging status for the Arrangement. This is left blank for product lines, other than
Lending.
Aging activity will have the Bill Type as an extended suffix.

OVERDUE.STATUS Field denotes the overdue or aging status of the arrangement. The list
of values allowed is equal to the list defined in EB.LOOKUP file with the ID like
AA.OVERDUE.STATUS*<odStatus>. For example, if PDO is an overdue status, then a
record in EB.LOOKUP File should be defined as AA.OVERDUE.STATUS*PDO.

AGEING.TYPE Field denotes whether the aging should be based on days or by bills. This
field is associated multivalue field starting from OVERDUE.STATUS to EFFECTIVE.DATE.
Allowed inputs are DAYS and BILLS.
If days, the value in the AGEING Field denotes number of days.
If bills, the value in the AGEING Field denotes number of bills.
A value of zero in this field indicates that the bill will move the overdue status on the
same day the bill was made due. A value of zero cannot be set to more than one
overdue status.

NOTICE.DAYS Field represents the calendar days post to a aging status that a chaser
advice to be sent.
NOTICE.FREQ Field represents a frequency in which the advice to be sent for the aging
status.
Both Notice days and frequency can be given, in which case, the system would produce
advice after the notice days and thereon based on the frequency set, advices would be
sent. If Notice days are not given, system would cycle the frequency based on the ageing
status change date.

AGE.ALL.BILLS Field is set to indicate that all bills under the arrangement should be aged
to this status. Usually this field is set to YES for a higher overdue status. Please note that
AA does not age any Activity charge bills that are due.
SUSPEND Field represents whether the arrangement needs to be suspended when the
current aging status is reached. To set to suspend, AGE.ALL.BILLS Field should be set to
“YES”.

MOVE.BALANCE Field denotes whether the balance needs to be moved to the

corresponding status. Input of YES would mean along with the arrangement, the due or
aging balance types would move to the new balance. The balance held in previous status
is made zero and stored in new balance
EFFECTIVE.DATE Field indicates the method of finding the value date for moving the
status of the bill as a result of ageing status movement. The allowed values are DUE or
STATUS or can be Blank.
DUE – All ageing status movement is based on the bill due date.
STATUS – Every ageing status movement is reckoned from the previous status.
Blank - The value date will be the bill's financial date.
Example: Suppose a bill has been made DUE on 10th March and its Financial date is say
on 12th March. Subsequently when the bill moves to GRA (Grace) overdue status , say
after 5 days from the due date, that is, on 15th March. The accounting value date for
various values in this field would be: -
DUE – 10th March
STATUS – 15th March
When blank – 12th March


PAY.TOLERANCE Field represents the tolerance percentage that needs to be applied on

the bill amount. The tolerance percentage is applied on the bill amount that was issued.
It is then compared with the current outstanding amount in bill. If the outstanding
amount is within the tolerance then the bill is not aged.
TOL.AMOUNT Field - Either percentage or tolerance amount can be defined. If the
currency defined in bill matches the TOL.CCY, then the tolerance amount is taken from
the field TOL.AMOUNT.
TOL.CCY Field denotes the tolerance currency. Either percentage or tolerance amount
can be defined. If the currency defined in bill matches the TOL.CCY, then the tolerance
amount is taken from the field TOL.AMOUNT.
TOL.ACTION Field denotes the action on which the tolerance is applied. Allowed values
are REPAY and REMAIN.

PAY.TOLERANCE Field represents the tolerance percentage that needs to be applied on

the bill amount. The tolerance percentage is applied on the bill amount that was issued.
It is then compared with the current outstanding amount in bill. If the outstanding
amount is within the tolerance then the bill is not aged.
TOL.AMOUNT Field - Either percentage or tolerance amount can be defined. If the
currency defined in bill matches the TOL.CCY, then the tolerance amount is taken from
the field TOL.AMOUNT.
TOL.CCY Field denotes the tolerance currency. Either percentage or tolerance amount
can be defined. If the currency defined in bill matches the TOL.CCY, then the tolerance
amount is taken from the field TOL.AMOUNT.
TOL.ACTION Field denotes the action on which the tolerance is applied. Allowed values
are REPAY and REMAIN.

It is possible to allow actual settlement of repayment amount towards overdue bills

which will still be based on the settlement sequence defined in PAYMENT.RULES
property class – which is by Property or by bill date and Property within the bill.
The bill may be deemed as settled from delinquency stand point but may contain
outstanding dues at the end of the settlement allocation.
This can be specified using the fields BILL.SETTLEMENT with a value of BILL.TOTAL and
AGE.BILLS set to BILL.STATUS.
BILL.SETTLEMENT Field represents whether settlement is against the total bill
outstanding to consider a bill for delinquency processing. Values allowed are BILL.TOTAL
and null. If value is BILL.TOTAL, original repayment amount is compared with the total
outstanding amount of the selected bill and if it happens to be greater than or equal to
total outstanding amount, the bill is deemed to be settled.

The field DELIN.OS.AMT in AA.BILL.DETAILS holds the outstanding Delinquency amount

pertaining to that bill
After make due, DELIN.OS.AMT is equal to the OS.TOTAL.AMOUNT, while repayment, if
the repayment amount is equal to the BILL.AMOUNT then the DELIN.OS.AMT field is
marked as 0 and the bill is marked as settled and the bill is not considered for ageing.
If the OS.TOTAL.AMT still exists for the bill, when further repayments are made the
OS.TOTAL.AMT in the bill is settled first

The delinquent bill is settled and the field AGING.STATUS is marked as SETTLED in the
AA.ACCOUNT.DETAILS record

In this example, 2 bills are made due to an extent of 100 each in which repayment
sequence is bill by property and the sequence is Account and then Interest

A repayment is made to an extent of 100 where the repayment sequence is by

BILL.PROPERTY (Seq: Account, Interest), as per delinquency setting the 100 should settle
the 1st bill and make the field DELIN.OS.AMT as 0

AGE.ALL.BILLS : This field is set to indicate that all bills under the arrangement should be
aged to this status. Usually this field is set to YES for a higher overdue status.
This is an optional field.
Validation Rules
Can take either YES or NO only.
AGE.BILLS Field denotes whether to consider the current bill for further aging when bill
is deemed to be settled, that is delinquent outstanding amount in the bill is zero. Valid
options are BILL.STATUS or SETTLE.STATUS
BILL.STATUS allowed only BILL.SETTLEMENT has value BILL.TOTAL

When few bills have aged and are in different / same overdue statuses based on the
overdue definition of the arrangement, on full settlement of one or more bills, the aging
statuses of the remaining bills will be recalculated. This full settlement can be of two
ways:
1) Full repayment of the outstanding amount of the bill. 2) Delinquent settlement such
that the settled bill does not age further.
However, for the above recalculation to happen the field STATUS.MVMT in overdue
property condition should be set as YES for the aging statuses for which recalculation is
required.
The activites that trigger these are :
1) LENDING-APPLYPAYMENT-PAYMENT.RULES
2) LENDING-UPDATE-OVERDUE
When the oldest bill moves to AGE.ALL.BILLS status, say NAB, all the due and aged bills
move to this status. If the oldest bill is deemed to be settled (as per delinquency setup)
or settled financially, then the rest of the un-settled bills move to their respective aging
status depending on the overdue definition. The balances also are reversed accordingly
to reflect the new aging status.
When user changes the overdue definition using the UPDATE activity, all the unsettled
bills are reclassified as per the changed overdue definition.

After a Bill is made due, it can be subject to an ageing process as per the OVERDUE
Property setting for the Arrangement.
A Bill can pass through different statuses. These statuses are user definable like GRA
(Grace), DEL (Delinquent), NAB (Non Accrual Basis), etc. In the OVERDUE Product
Condition, you can define the time period for a Bill to pass through different statuses
and related parameters.
You can set up the various Overdue Statuses in the virtual table AA.OVERDUE.STATUS
using EB.LOOKUP.

The Overdue Age activity will be triggered during the Close of Business based upon the
due dates of outstanding bills and the ageing rules that have been defined for each
overdue status.
Should an outstanding bill be subject to ageing the activity will be determined based on
the payment tolerance defined in the Overdue Condition and the Bill’s outstanding
amount.
If a bill is to be aged, the status of the bill will be updated, the specified accounting rule
will be applied (subject to the balance movement attributes) and any applicable charges
will be initiated.
If a bill is not aged due to payment tolerance rules, its status will either remain as it is or
be changed to Repaid and accounting will be triggered.
The Issue Chaser activity will be initiated if a number of notice days have been specified
or a notice frequency. This activity will generate the appropriate message details and the
notice specified in Activity Messaging will be sent via delivery. The Update activity is
initiated manually by the user in order to update any of the attributes of the Overdue.

AA.OVERDUE.STATS is used to record information on any overdue status the

arrangement has reached through its current life cycle, for analysis purpose. E.g.
number of times the arrangement reached a certain Overdue status, total number of
days at each Overdue status, average amount and the dates on which funds have moved
into and out of a particular aging status. The field OD.STATUS is updated when the first
bill reaches its first overdue status.
It contains BILL.TYPE in id to identify for what BILL.TYPE aging status has been evaluated.
START.DATE and END.DATE are the dates in which the arrangement has overdue amounts
in that respective overdue status.
PRD.AVG.AMT - Records the average overdue amount for a particular period within the
same overdue status. This amount is arrived at by calculating a daily average of the
closing balances for that period.
STATUS.COUNT – Records the number of the times the arrangement had moved in and
came out of the Particular Overdue status.
AVG.AMT – Records the overall average amount that is lying in the respective overdue
status which is arrived by adding the period average balances and dividing the same by
number of times the arrangement has moved in and out of the perspective overdue
status.

Create a Overdue Product condition with the following Settings:

Grace Status – 1 day after due, balances are not to be moved
Delinquent – 5 days after due, notice to be generated 1 day post aging
status and once in 2 weeks thereafter. Balances to be moved. Penalty
interest to be charged from value date of Bill
Non Accrual Basis – 60 days after due – notice to be generated every
week. Balances to be moved. Arrangement to be suspended. All bills to
be aged to NAB Status. Penalty interest to be charged from Overdue
status change date.
Dues not to be aged when current outstanding is within 2% of bill amount and
status to REMAIN.

In this workshop, we are going to create a new Overdue Product Condition.

Set the following rules:
Grace Status – 1 day after due, balances are not to be moved
Delinquent – 5 days after due, notice to be generated 1 day post aging
status and once in 2 weeks thereafter. Balances to be moved. Penalty
interest to be charged from value date of Bill
Non Accrual Basis – 60 days after due – notice to be generated every
week. Balances to be moved. Arrangement to be suspended. All bills to
be aged to NAB Status. Penalty interest to be charged from Overdue
status change date.
Dues not to be aged when current outstanding is within 2% of bill amount and
status to REMAIN.
Recalculation to happen during delinquent settlement in NAB status.

Create a Overdue Product Condition with the following settings:

Set the following rules
Delinquent when 2 bills are overdue, Notice to be generated
automatically after 1 day of status movement and then every two weeks.
Balances to be moved. Penalty interest to be charged from value date of
Bill
Non Accrual Basis when 6 bills are overdue. Notice to be generated every
week. Arrangement to be suspended. All bills to be moved to this status.
Balances to be moved. Penalty interest to be charged from Overdue
status change date.
Dues not to be aged when current outstanding is within USD 5 and to be treated
as remain.

In this workshop, we are going to create a new Overdue Product Condition with the
following Settings:
Set the following rules
Delinquent when 2 bills are overdue, Notice to be generated
automatically after 1 day of status movement and then every two weeks.
Balances to be moved. Penalty interest to be charged from value date of
Bill
Non Accrual Basis when 6 bills are overdue. Notice to be generated every
week. Arrangement to be suspended. All bills to be moved to this status.
Balances to be moved. Penalty interest to be charged from Overdue
status change date.
Dues not to be aged when current outstanding is within USD 5 and to be treated
as re.ain


AALendingAdvancedPart2 PDF

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

AALendingAdvancedPart2 PDF

Uploaded by

Copyright:

Available Formats

AA Lending Advanced - Part 2

Temenos University - November 2012 1

Temenos University - November 2012 2

PAYMENT.SCHEDULE is a mandatory Property Class of LENDING Product Line.

Temenos University - November 2012 3

Temenos University - November 2012 4

PAYMENT.TYPE Field denotes different types of calculated payments that could be

Temenos University - November 2012 5

CONSTANT - Instalment in fixed or equated amounts is called Constant or Annuity type.

Temenos University - November 2012 6

Temenos University - November 2012 7

Temenos University - November 2012 8

Temenos University - November 2012 9

Temenos University - November 2012 10

Temenos University - November 2012 11

Temenos University - November 2012 12

Temenos University - November 2012 13

Temenos University - November 2012 14

Temenos University - November 2012 15

PAYMENT.FREQ field indicates frequency at which payments will be made due.

Temenos University - November 2012 16

Temenos University - November 2012 17

Temenos University - November 2012 18

In this example, we are creating an arrangement with repayment schedule to start 1

Temenos University - November 2012 19

Temenos University - November 2012 20

UPDATE – CHARGE, CHANGE – INTEREST, CHANGE– PAYMENT.SCHEDULE, CHANGE.TERM

Temenos University - November 2012 21

Temenos University - November 2012 22

Temenos University - November 2012 23

Temenos University - November 2012 24

Temenos University - November 2012 25

Temenos University - November 2012 26

Temenos University - November 2012 27

Temenos University - November 2012 28

Temenos University - November 2012 29

Temenos University - November 2012 30

It is possible to include regular and ad-hoc (recurring and non-recurring) additional

Temenos University - November 2012 31

Temenos University - November 2012 32

Temenos University - November 2012 33

Certain Activities have an impact on the Payment Schedules.

Temenos University - November 2012 34

Temenos University - November 2012 35

Temenos University - November 2012 36

Temenos University - November 2012 37

Temenos University - November 2012 38

Create a Product condition for Linear Payments

Temenos University - November 2012 39

Temenos University - November 2012 40

Temenos University - November 2012 41

Temenos University - November 2012 42

PAYMENT.RULES is a mandatory Property Class of LENDING Product Line.

Temenos University - November 2012 43

Temenos University - November 2012 44

Temenos University - November 2012 45

Temenos University - November 2012 46

Temenos University - November 2012 47

Temenos University - November 2012 48

Current: Payment will be applied on arrangement's current balances. (e.g. current

Temenos University - November 2012 49

Temenos University - November 2012 50