AALendingAdvancedPart3 PDF

AA Lending Advanced - Part 3
Temenos University - Novembre 2012 1


CHANGE.PRODUCT is an optional Property Class of LENDING Product Line. It can be used

to change an Arrangement’s Product after a certain period.

CHARGE property class is of a dated, optional currency type. Multiple properties are
allowed for a product. During an activity, if permitted, user can amend or delete any of
the future conditions. Charge property holds charge balances.
Credit in Property type field of a charge property denotes that this charge is payable.

CHARGE.TYPE Field defines if the charge amount is fixed amount or to be calculated

based on the input in rest of the fields. It can accept two values either FIXED or
CALCULATED.
If FIXED then FIXED.AMOUNT Field is mandatory and this would be returned as the
charge amount.
If CALCULATED then charge amount will be calculated based on the definitions in rest of
fields.

The CHARGE Property Class differs from other Currency Specific classes in that it
includes a CURRENCY field. This field defaults to the currency of the record and specifies
in which currency the charge is defined and which currency the charge will be applied.
Specifying the currency in a separate field allows for the following capabilities:
Charging in a currency different from that of the Arrangement (i.e. with charges defined
in a currency which is different than the record’s currency) For example the product
charges may be defined in USD for arrangements in all currencies, but a different set of
charge tariffs may be defined for contracts in different currencies but also in USD. So a
GBP contract may attract a charge of 10 USD and a EUR contract may attract a charge of
20 USD.
Default Currency charging – In this (optional currency) case a currency need not be
specified in the ID of the record and the user will have to set the Currency field
explicitly. Any arrangement which is in a currency for which a currency specific record
has not been defined will use this default record and calculate/apply the charge in the
currency specified in the currency field.
The calculated charge should be converted to the arrangement currency at the prevailing
mid-rate (stored on the CURRENCY table) when applied.

Here, you will see how the calculation will differ when the Tier Group is Level or Band.
You will see that the Tier Amounts are in ascending order and the last Tier Amount is
null. Upto 20,000 the Level Tier Type is used and from 30,000 Band Tier Type is used.
When the Tier Group is Level, system will use the calculation method of the Tier Type in
which the amount is located.
Here the amount 50,000 is located in the second tier type which uses Band type
calculation and the amount will be calculated using the Band type of calculation and
given rates.
When the Tier Group is Band, system will use the Band type of calculation.
However, in this case, any Level Tier Group used, will return the amount based on Level
type calculation.

CALC.TYPE defines charge calculation type to be applied for charge calculations.

It will accept FLAT, PERCENTAGE, UNIT.
FLAT - Amount defined in CHG.AMOUNT to be used for the associated tier set.
PERCENTAGE - Rate defined in CHARGE.RATE to be applied for the associated tier set.
UNIT - Multiplication factor defined in CHG.AMOUNT to be applied for calculating
charge.

CHARGE.RATE Field if defined will multiply the rate that has been defined here with the
amount that falls in this tier set to get the charge amount. This field is mandatory when
CALC.TYPE is PERCENTAGE.
CHG.AMOUNT Field: Behaviour of this field is based on CALC.TYPE.
If CALC.TYPE is FLAT then amount defined in this field will be taken as charge amount for
the associated tier.
If CALC.TYPE is UNIT then value defined in this field will be multiplied with the amount
that falls in this tier set to get the charge amount.
Both CHARGE.RATE and CHG.AMOUNT cannot be input.

Charge minimums and maximums can be specified in two ways:

Tier Level – the user can specify a minimum and/or maximum charge amount for each
tier defined. These rates are defined in tier minimum charge and tier maximum
charge.
Overall – the user can specify overall minimum and/or maximum charges through the
user of two Periodic Attributes. EB.ROUNDING.RULE to override the currency specified
method.
Complex charges can be defined, AA.LOCAL.CALC.CHARGE.AMOUNT routine is attached
to the field CHARGE.ROUTINE to calculate the charge amount.
Say, Interest is calculated on the amount being withdrawn for the current period and the
interest amount is levied as charge amount. Principal Amount – 10000, Interest Period
Start date - 1st June 2010, Interest Period End date - 15th June 2010, Current Date - 10th
June 2010, Withdrawal Amount – 4000, Day basis – E, Interest Rate - 6%, Charge Amount
= (4000 * 10 * 6%) / 365 = 5.47. If tolerance is set for withdrawal in
ACTIVITY.RESTRICTION, charge is calculated on base amount and not on withdrawal
amount. Base amount is the difference of withdrawal amount and tolerance percentage.
CALC.THRESHOLD Field defines the threshold amount (base amount) below which
charge amount will not be calculated.

CALC.THRESHOLD Field defines the threshold amount (base amount) below which
charge amount will not be calculated.
A user can specify that a charge will only be calculated if an amount threshold is
surpassed. The threshold amount is of the same base type (i.e. activity amount, balance,
activity count) as the base type for which the charge is being calculated and is defined in
calculation threshold.
FREE.AMOUNT Field - if defined the final charge amount will be the calculated charge
amount less the amount specified in this field.
An amount which will be deducted from the total calculated charge subject to any
minimum and maximum which may be specified- defined in free amount

MIN.CHG.AMOUNT - For an arrangement, it is possible to specify minimum charge

amount. This minimum charge will be compared with the computed charge amount, and
if the same is less than the minimum, it can be decided to waive or charge through
MIN.CHG.WAIVE.
If MIN.CHG.WAIVE Field is set as YES, no amount would be charged, otherwise the
minimum amount would be charged.

Create a Charge Product condition for collecting a fixed charge with all attributes set as
negotiable by default.

In this workshop, we will see how to create a Charge Product condition for collecting a
Fixed charge.
Set the following rules:
A Fixed Charge of USD 100,
All Attributes are negotiable by default.

Create a Charge Product condition for collecting a calculated, banded charge with the
following settings:
Charges in USD.
No charges for transaction amount up to 3,000.
2% for transaction amount up to 20,000 with a minimum of 100.
Additonally1.5% for transaction amount beyond 20,000 and up to 50,000
with a minimum of 500 .
Additionally 1% for transaction amount over 50,000 subject to a
minimum of 800 and maximum of 2,000.
All Attributes are negotiable by default.

In this workshop, we will see how to create a Charge Product condition for collecting a
calculated, banded charge.
Charges are calculated and collected in USD
Tier groups are banded
2% for transaction amount up to 20,000 with a minimum of 100
Additonally1.5% for transaction amount beyond 20,000 and up to 50,000
with a minimum of 500
Additionally 1% for transaction amount over 50,000 subject to a
minimum of 800 and maximum of 2,000
No charges for transaction amount up to 3,000
All Attributes are negotiable by default



Activity Charges control the application of charges when specific activities take place in
the life of an arrangement.

ACTIVITY.ID Field denotes the activity on which the charge would be applied. Should be
valid record id in the file AA.ACTIVITY.
CHARGE Field indicates the charge property that is triggered when the corresponding
activity is triggered. This field is associated with the ACTIVITY.ID field. The charge defined
will correspond to CHARGE property. These properties and their conditions would be
defined in the product designer of a product. Should be a valid AA.PROPERTY belonging
to the CHARGE property class.

APP.PERIOD Field accepts a valid T24 period. This denotes the application period for
current application Method.
APP.METHOD Field can have values DUE or CAPITALISE or DEFER. It denotes which
application method (DUE or CAPITALISE or DEFER) should be taken while applying
activity charges.
The activity/rule break If DEFER is specified the system will calculate the charge and
update the charge details in AA.CHARGE.DETAILS. In this instance no bills will be
generated for the charge and charges will be collected at a later point
The Deferred Charges should be defined in the Payment Schedule to mention when the
charges will be collected. On this date, system will check the AA.CHARGE.DETAILS with
APP.METHOD as DEFER. Then system will do an ISSUEBILL for all the Deferred charges
that are yet to be collected. At this stage, the Bill Id will be updated for all the amounts
deferred for this property during the Issue Bill event.

It is possible to settle activity charges through settlement property. All Activity Charges
are grouped under the payment type ACTCHARGES, when defined in the Payment
Schedule Product Condition. Activity Charges look in the Settlement Property for this
payment type and fetches the corresponding settlement instructions.
The Settle Activity is defined in Activity Charges Product condition.

The Settle Activity is defined in Activity Charges Product condition. Defines the
repayment activity to be triggered when there is unallocated credit. It is triggered as a
secondary activity of Activity charges make due. 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.

Create an Activity Charge Product condition with the following Settings:

Charge to be levied when a new arrangement is opened
The Charge Property is NEWARRFEE
New Arrangement Fee to be made Due on occurrence of activity
All Attributes are not negotiable by default

In this workshop, we will see how to create an Activity Charge Product condition.
Charge to be levied when a new Loan Arrangement is opened,
The Charge Property is NEWARRFEE,
This New Arrangement Fee to be made Due on Occurrence of the activity
All Attributes are not negotiable by default

Charges are also related to PAYMENT.SCHEDULE Property Class as well as with other
Property Classes where a Periodic Rule can be defined.
CHARGE is the basic Property Class in which attributes for calculation of charges will be
set up.
There are three occasions when charges can be levied for an Arrangement.
When an Activity is processed, the property class ACTIVITY.CHARGES defines the
Activities which need to be charged.
Periodical collection of Charges, whose frequency and type are defined in Payment
Schedules.
Finally, levied when a Periodical Rule is broken. The Periodic Rules can be defined in
specific Product Conditions.
In all these cases, a Charge Property will be linked. In the Product definition, this Charge
Property will be attached with an appropriate Charge Product Condition.
APP.METHOD field in AA.PRD.DES.ACTIVITY.CHARGES is used to specify whether activity
charge amount will be due or capitalised
PAYMENT.METHOD field in AA.PRD.DES.PAYMENT.SCHEDULE is used to specify whether
.scheduled charge amount will be due or capitalised.

You can specify in a Payment Schedule attached to your Product, a Charge Property with
a frequency for collection.
In your Product, you have to attach both the PAYMENT.SCHEDULE Property and its linked
Charge Property.
You will be linking the PAYMENT.SCHEDULE Property with a Condition and the CHARGE
Property with a Condition.
In the Charge Product Condition, you can define either a flat charge or a calculated
charge depending on a balance type specified in AA.SOURCE.CALC.TYPE. For example,
you can define a quarterly charge on the highest debit balance for the quarter.

In this example, we are setting up a payment schedule product condition with Schedule
charge for 3 months and defining a Fixed charge product condition.

In this example, we are attaching Product condition created with Charges for Payment
Schedule Property and attach Charge product condition created to the Charge property
defined in the payment schedule. If charge type is calculated specify the calculation
source for the charge property in the Calculation Source Tab in the Product designer.

In this example, we are creating a new arrangement for USD 100000 for 1year and view
the payment schedule with Charge property which is made due every 3 months once.

In this example, we can view the payment schedule Interest and Principal made due
monthly and the Maintenance Fee is made due every 3 months once as per the product
conditions

You can specify periodic rules in specific Product Conditions. For example, in a
TERM.AMOUNT Product Condition, you can attach a Periodic Rule which sets that the
increase in Commitment amount over a period of 1 year cannot exceed 10%.
When you link such periodic rules in a Product Condition, you can also link a Charge
Property, to be collected when the rule is broken. The charge can be a fixed amount or
calculated on a base amount.

If the rule Full Disbursement is not made an override is generated with a Rule Break
charge Property Disbursement Fee for which a Charge product condition will be
attached in the product designer.

You can charge specific Activities like creating a new Arrangement, disbursing a
commitment amount and when the status of an Overdue Bill changes for instance to
delinquent status.
There is a separate Property Class ACTIVITY.CHARGE, in which you can link specific
Activities to Charge Properties.
In your Product, you have to attach both the ACTIVITY.CHARGE Property and its linked
Charge Property.
You will be linking the ACTIVITY.CHARGE Property with a Condition and the CHARGE
Property with a Condition.
In the Charge Product Condition, you can define either a flat charge or a calculated
charge depending on a balance type specified in AA.SOURCE.CALC.TYPE. For example,
when you charge the Activity to disburse a Commitment, the charge can be based on the
disbursement amount.

An Activity Charges product condition is set up for new arrangement creation.

Charge product condition with 1% created for New Arrangement creation

Activity Charge product condition created is attached to the Activity Charges property
and 1% New arrangement Fee charge product condition is attached to the Charge
Property (linked to Activity Charge Product Condition).
Calculation Source – Specifies the Charge to be calculated on what balance type. Since
the Charge type is Calculated we are specifying NEWARRFEE (1%) to be calculated the
CURCOMMITMENTBalance.

An Arrangement is created for USD 100000, period of 1 year.

An Activity Charge is triggered for the New arrangement creation for USD 1000.
The calculation is based on the calculation source specified in the product designer as
we have defined charge to be calculated on CURCOMMITMENT which is 100000 the
charge calculated amount is USD 1000 (1% on USD 100000)



CHARGE. OVERRIDE property does not appear when the user activity is input initially. It
appears only after validating the record and if charges are applicable for the transaction.
If applicable, the property appears in the arrangement after an Activity charge is
triggered and validated.

Charges for an arrangement can be raised in various ways. When an activity charge or a
periodic charge is triggered, an override is generated and the default charges are shown.
Based on the default charges it is possible to waive the charges accordingly, any
modifications made will raise new entries for the new charge amount.
Charge (Property) – Holds the charge property for which the charge is collected.
When a user inputs an activity which triggers an activity charge or a periodic charge, or
when a rule is broken, on committing the activity, the default charge amount will be
populated in the field CHG.AMT. User can modify the charge by inputting a fresh charge
amount in the field CHG.ACT.AMT. The value could be Null, Zero or a numerical value.
Charges are waived completely if value 0 is input and default charge would be levied if
the field is left blank. The respective charge would be levied if a modified amount is
input. User can modify this charge by inputting a new charge amount in this field, if left
negotiable.

Charge Description - Description about why the charge has been negotiated when
triggering the activity.
Charge Type - This field specifies what type of charge is being collected. This is also
automatically populated by the system depending upon the charge calculated.
It can accept 2 values 'ACT.CHARGE' - Activity Charge; 'PR.CHARGE' - Periodic Charge.
If more than one charge is attached for the same activity user will be able to
modify/waive all. For this purpose, a new property class ‘CHARGE.OVERRIDE’ is
available.
Charges collected during payoff or charges collected during repayment and
disbursement cannot be modified or waived as these pertain to Activities created on
account transactions from external applications.

Initially Charge override will not appear in the Arrangement screen, the Property
appears in an arrangement only after an Activity charge or Periodic rule break
charge is triggered and validated

The Charge Override property does not initially appear as charges may not be specified.
Only after a validation and if charges are applicable for the transaction it will appear.


Create a Charge Override Product condition with the following:

2 Charge Properties - NEWARRFEE, PRINDECREASEFEE to be indicated
under Property
Input Charge Actual Amount as 500 against NEWARRFEE

In this workshop, we will see how to create a Charge Override Product condition.
Set the following conditions:
2 Charge Properties - NEWARRFEE, PRINDECREASEFEE to be indicated
under Property
Input Charge Actual Amount of 500 against NEWARRFEE



The PERIODIC.CHARGES Property class is used to make the deferred charges due at fixed
intervals. This needs to be defined as part of the payment schedule definition and
property condition determines the charges to be made due. It supports the following
arrangement links: DATED and OPT.CCY.
This Property Class does not have any balance types

INC.ALL.DEF.CHGS Field– This attribute denotes on the scheduled date whether all the
deferred charges to be made due.
DEFERRED CHARGE Field – This attribute is a Multi value field. User can multi value this
and Specify the charge property names that are deferred and to be made due.
The above said attributes can be set either at the product level or at the arrangement
level.
At the arrangement level it is possible to change value in field INC.ALL.DEF.CHGS
defaulted from product level and to specify the charge to be deferred in the field
DEFERRED.CHARGE. For example, charges are to be collected for activities LENDING-
NEW-ARRANGEMENT and LENDING-APPLYPAYMENT-PR.PRINCIPALDECREASE. Field
APP.METHOD is set to DEFER in ACTIVITY.CHARGES property class. On specifying the
PERIODIC.CHARGES property in the PAYMENT SCHEDULE, system will collect all the
deferred charges on the scheduled date if the field INC.ALL.DEF.CHGS is set to YES in
PERIODIC.CHARGES property. If the field INC.ALL.DEF.CHGS is set to No then the charge
specified in the field DEFERRED.CHARGES alone will be collected on the scheduled date.



CHANGE.PRODUCT Property Class is DATE and TRACKING type.

The CHANGE.PRODUCT property can be included in a product if arrangements are
allowed to be changed to another product during its lifetime or if any arrangement is to
be renewed in its lifetime. The property class allows the definition of restricted products
that change can be made to and when a scheduled change should be applied.
Existing Arrangements can be changed to a different product either manually or
automatically on a scheduled date.

ALLOWED.PRODUCT Field is used to list products to which the arrangement product can
switch to. All the products should belong to the same product group. If this field is left
blank, the arrangement product is allowed to switch to all products of the same group.
When the product is proofed it will verify that the allowed products belong to the same
AA.PRODUCT.GROUP as the product being published, if not a proofing error is generated
and must be corrected before the product can be published.

CHANGE.DATE field indicates the date on which the arrangement would change from a
existing product to a new product. System ignores DATE.CONVENTION.
CHANGE.PERIOD is used to define a Product for arrangement to change to after a period
of time. A period (say 6M, 12M) may be stated in this field. The arrangement start date
would be considered as the base date for computing the period. For subsequent change
product events, the last change product date is considered as base date and not the
arrangement start date. Both CHANGE.DATE and CHANGE.PERIOD are not allowed
together.
PRIOR.DAYS Field is used to specify days by which the change activity to happen in
advance to scheduled date of change. This will be helpful to negotiate the terms of new
product.
The system can process the activity to change the arrangement product a number of
days in advance of the actual change date. This can be done to allow sufficient time for
communication of new conditions to the client prior to the start of the new product.
The system will generate all the new conditions according to the PRIOR.DAYS definition
associated with the CHG.TO.PRODUCT. On the change date less the number of prior days
the new product change conditions will be generated with an effective date equal to the
CHANGE.DATE (or date calculated as arrangement start date plus CHANGE.PERIOD).
It is possible to calculate the change product date relative to the birth date of a
customer. For example:
A customer who currently holds a minor account, reaches the age where he is
considered to be a major. The field CHANGE.PERIOD accepts relative period such that
user can indicate the change date to be a calculated date, relative to the customer’s
birth date.

CHANGE.ACTIVITY - This Field will determines which Activity will be triggered during
Loan Renewal. Mandatory if RENEWAL.DATE is used. Available Options are ROLLOVER,
RESET, CHANGE.PRODUCT
CHG.TO.PRODUCT - The product to which the arrangement must switch to on this date
or period. The product must be one in the allowed list of products. It should belong to
the same group as that of the arrangement product.

INITIATION.TYPE Field is used to determine whether the renewal activity to happen

automatically on a specified date or to be triggered manually by user. If not done
manually on renewal, default activity will be activated. DEFAULT.ACTIVITY Field will
determine the default Activity which will be triggered when INITIATION.TYPE is equal to
MANUAL. Currently it can accept only ROLLOVER Activity.
Majority of Arrangement conditions will be overwritten by the new Product’s default
values. The exceptions are Customer, Account, Term Amount and Limit. Loan Renewal
could trigger several Activities which can be run by the user or in some cases
automatically scheduled which can be used to change any of the conditions of the
Arrangement and in some cases will result in the recalculation of a Renewal Date and
the Maturity Date.

ROLLOVER would renew with the existing Arrangement conditions . The product
conditions will not be considered except for the properties that track the product
conditions.
RENEWAL.DATE field in AA.ACCOUNT.DETAILS for the specified account will be updated
during the New Arrangement(If Change Product Property is attached to the Product) is
rolled over.

RESET - This activity is triggered on the calculated or user defined renewal date when the
CHANGE.ACTIVITY is set to LENDING- RESET-ARRANGEMENT in CHANGE.PRODUCT
property condition and resets the current conditions of the product for which
DEFAULT.ATTR.OPTION is set to RESETTING. However, conditions can be renegotiated by
the user at any point of time. This also calculates the next renewal date and optionally
the maturity date. The same can be triggered manually too.
The renewal date will be updated in AA.ACCOUNT.DETAILS which is calculated based on

payment end date. Arrangement will be reset with current conditions. Maturity date &
renewal date recalculated based on payment end date.

This activity is triggered on the calculated or user defined renewal date when the
CHANGE.ACTIVITY is set to LENDING-CHANGE.PRODUCT-ARRANGEMENT in
CHANGE.PRODUCT property condition and also resets the currents conditions of the
new product based on the value in DEFAULT.ATTR.OPTION in the old product. The same
can be scheduled or triggered manually.
rolled over

When there is a change in condition scheduled for a product, same will be applied only if
DEFAULT.ATTR.OPTION Field in CHANGE.PRODUCT product condition has value as
RESETTING. If value is NON-RESETTING or NONE, new condition will not take effect for
the arrangement.
rolled over
LENDING-RENEGOTIATE-ARRANGEMENT can be used to change the arrangement
conditions of different properties at one stretch.

AA.ARRANGEMENT will specify the status of the product. Three options indicate the
status of the product.
PROCESSED – Once the arrangement moves from old product to new product, status of
old product will be updated as PROCESSED.
CURRENT – This indicates that the arrangement is running on the current product.
SCHEDULED – If the product is scheduled for a future date status is updated as
SCHEDULED.

Create a Change Product condition with the following Settings:

Change period is 6 months
Set LENDING-RESET-ARRANGEMENT activity for Change activity
Switch to happen 3 days in advance to Change Period

In this workshop, we will see how to create a Change Product condition.

Set the following conditions:
Change period is 6 months
Set LENDING-RESET-ARRANGEMENT activity for Change activity
Switch to happen 3 days in advance to Change Period

PAYOFF property class can be included in products where user wants to generate payoff
statement at arrangement level. Payoff statement should include all Principal, Interest
and Charges that will be due as a result of payoff.
Payoff calculation produces a record with itemised calculated amounts. It adjusts the
system calculated amounts and shows the adjusted amounts along with the original
calculated amounts in payoff statement. Whenever a new payoff statement is requested,
the old one is deleted and a new payoff bill is created.

PAYOFF Property class is DATED, TRACKING type. The existing repayment functionality
applies.
This property class is extensively used in simulation. This property class does not have
any related financial balances.

The payoff amounts would be calculated using simulation framework.

EXPIRY.DAYS Field is used to define expiry date for the payoff bill. The number of days
defined would be taken as working days and expiry date for the payoff bill would be
calculated as payoff date plus the number of working days defined in this field. When
the expiry date is reached the payoff bill would be purged (deleted).
SETTLE.ACT Field defines settlement activity to be automatically invoked while

calculating payoff amount in simulation mode or when the arrangement is paid off in live
using SETTLE activity of PAYOFF property class. This allocation activity would be used to
settle the pay-off bill. This activity would be run against the pay-off activity to calculate
the pre-payment penalty charges. Any prepayment charges needs to be attached to this
activity.

When there are existing dues, apart from current dues, system will look for settlement
definitions under Payment rules product condition.
SETTLE.DUE.ACT Field defines settlement activity to be automatically invoked when due
amounts between simulation start date and payoff effective date are to considered as
settled. When the arrangement has unallocated credit balance during a payoff request,
this UNC balance is reduced to arrive at the payoff amount.

Payoff bill is generated either via the application AA.SIMULATION.CAPTURE or

AA.ARRANGEMENT.ACTIVITY.
Payoff bill creation using simulation capture:
Steps in involved in creating payoff via simulation capture.
1. Input simulation capture for an arrangement with activity set to LENDING-
CALCULATE-PAYOFF.
2. Field EFFECTIVE.DATE indicates whether payoff date is forward or today
3. The simulation capture system would trigger the activity LENDING-ISSUE-PAYOFF and
creates a record in AA.SIMULATION.RUNNER. Simulation runner would have the list of
activities to be triggered from today to payoff. Authorising the simulation capture and
running the service AA.SIMULATION.SERVICE system would update the $SIM files.
4. When the user commit and authorise the simulation runner with flag
EXECUTE.SIMULATION set to YES and running the service AA.SIMULATION.SERVICE
system writes the payoff bill in live files.

Payoffs can be requested at any point during the life of the loan contract and the
effective date can be either equal to the system date or can be forward dated. The
payoff statement are for only information so the customer is not expected to make the
payment on the payoff effective date. It is another simulation activity like Loan
modelling.
Activity Lending-Calculate-Payoff can only be run in simulation mode and cannot be
triggered by the user or scheduled. The activity should use the “Calculate” action to
calculate the payoff amounts. The action routine calculates the total outstanding
amount of the Loan contract as on the payoff date, including all overdue amounts and
current amounts.
SIMULATION.RUNNER front-end is used to simulate Lending-Calculate-Payoff activity
with the simulation end date as the required payoff and the payoff activity need to be
captured with the activity date as the required payoff date.
Prepayment charges may be set as a periodic rule or activity charge. Usually banks allow
prepayments up to a certain limit, which can be a percentage of the loan amount or a
fixed amount for a rolling period – anniversary period i.e. in a year the customer would
be allowed to prepay a percentage of the loan and is usually cumulative. To define this in
AA, a periodic rule can be setup in Payment Rules property to calculate the prepayment
charges when excess prepayments are done. Or the prepayment charges may simply be
a fixed amount which could be setup as Activity Charges on prepayment activity.

A new Activity is needed to calculate the payoff amount for a loan on an effective date.
This activity can only be run through the simulation mechanism. If the payoff date is in
future it is possible that it may be after several expected regular payment dates. In such
cases there could be automatic repayment of such dues or they could be treated as
unpaid dues. When running the simulation scenario a user can choose to “uncheck” any
future payments or add any other transaction as they do with any other simulation.
During simulation, system will simulate all of the scheduled activities, any user specified
activities and accruals up to the effective date. At the end of the simulation process (up
to the payoff date) bills are created for all regular payments as well for any rule (Periodic
Rules, Activity Charges) break charges. Based on the related activity for make-due
activity the bills for regular payments may be settled or would be overdue.
The payoff statement includes current balances which are not yet due to pay off the loan
contract fully. The “calculate” action routine gets all the properties linked to the
Arrangement for the property classes “Account”, “Interest” and “Charge”.
Any credit in unallocated credit balance (UNC) of Account property is automatically used
to settle the dues as and when they are created. The credit balance would be used only
to settle regular dues and not for any dues resulting due to charges on activities or rule
break charges.

In this example, we are viewing the payoff product condition used in the product
MARGIN LOANS

In this example, view the arrangement , activity log and the balances before requesting
payoff for the arrangement.

In this example, payoff is done for a forward date with SETTLE.DUES set as “YES”.
After committing the calculate payoff activity Simulation capture would trigger
the activity LENDING-ISSUE-PAYOFF and creates a record in
AA.SIMULATION.RUNNER, Simulation runner would have the list of activities to
be triggered from today to payoff.
The simulation runner with flag EXECUTE.SIMULATION set to YES and run the
service AA.SIMULATION.SERVICE system writes the payoff bill in live files.

After Simulating the payoff we can view the Payoff Bill issue activity in the Activity log
and the Payoff bill amount through “BILLS”
Since the product conditions have the Expiry days as “3” Payoff bill is shown for the
Effective date plus 3 User defined days.

Create a PAYOFF Product condition with the following Settings:

Set LENDING-APPLYPAYMENT-PR.PAYOFF to Settlement Activity
Enable auto settlement of future dues
Set to invoke LENDING-APPLYPAYMENT-PR.REPAYMENT activity automatically
when due to be considered settled between simulation start date and payoff
effective date
All attributes are negotiable by default


CLOSURE Property Class is a mandatory property class and it handles closure of

arrangements for LENDING product line. The reversal of new arrangement activity
results in creation of an ACCOUNT.CLOSURE request for the arrangement account.

CLOSURE Property class is DATED and TRACKING type.

This property class does not have any related financial balances.
After creating a new arrangement for loan, there are occasions, when a customer does
not want to proceed with the loan and wants to cancel the same. For this, user should
trigger LENDING-CANCEL-ARRANGEMENT which will raise entries opposite to entries
raised for new arrangement. After the arrangement has been cancelled, the
arrangement account needs to be closed. For this, system would trigger the LENDING-
CLOSE-ARRANGEMENT as a secondary activity during cancellation. At the cancellation
stage, status of the arrangement would be updated to PENDING.CLOSURE. System would
schedule the closure activity based on the closure period in CLOSURE property
condition. An account closure record (when the close activity is processed) will be
created for the arrangement in the ACCOUNT.CLOSURE application with a POSTING
RESTRICT of 90.

CLOSURE. METHOD Field - Valid options are Automatic & Manual. Specifies whether
closure processing would be triggered automatically or manually
CLOSURE.TYPE Field - Valid options are MATURITY or BALANCE. The Account associated
to an arrangement can be automatically closed either when all balances of the
arrangement becomes Zero or when arrangement matures provided all the balances are
settled. This can be defined in the field Closure Type. The field can hold values
“BALANCE”, “MATURITY” and “NONE”. If BALANCE is selected, the account would get
closed on the same day in which the account balance becomes Zero based on the
CLOSURE.PERIOD. If MATURITY is selected, once all balances are settled, the
ARR.STATUS field would be updated to PENDING.CLOSURE and account closure activity
would be scheduled on the date of maturity of the arrangement based on the
CLOSURE.PERIOD. None is applicable only if CLOSURE.METHOD is chosen as “MANUAL”.

CLOSURE.PERIOD Field - In case of automatic closure, this specifies the period when the
CLOSURE activity LENDING-CLOSE-ARRANGEMENT would be processed. This period
begins after the system has identified whether the arrangement is ready to be closed as
defined in CLOSURE.TYPE Field. The activity can also be triggered manually any time
during the period mentioned in CLOSURE.PERIOD after the balances become Zero except
for revolving arrangements. For revolving arrangements, the activity could be triggered
only after the maturity period.
POSTING.RESTRICT Field - Specifies the account closure posting restriction code. This
would be used to update ACCOUNT.CLOSURE application. A posting restrict in the range
of 90 -99 is allowed which pertains to account closure posting restrict.
Based on the CLOSURE.TYPE arrangement status would be flagged to
PENDING.CLOSURE.
The activities that are related to this property are:
LENDING-CLOSE-ARRANGEMENT – Once the arrangement is identified for closure based
on the closure settings in the closure product condition, LENDING-CLOSE-
ARRANGEMENT is triggered. This activity is automatically triggered if the closure method
is selected “AUTOMATIC” and needs to be triggered manually if closure method is
selected “MANUAL”.

In this scenario, CLOSURE METHOD is AUTOMATIC with CLOSURE.TYPE as MATURITY and

CLOSURE.PERIOD is 1 month.
After all balances are settled well before maturity, status of the arrangement and field
ARR.STATUS has been updated to PENDING.CLOSURE

On maturity the arrangement is updated with status as CLOSE in ARR.STATUS and

ACCOUNT.CLOSURE record is created with a POSTING.RESTRICT field set as 90.

Create a Closure Product condition for closure on maturity with the following Settings:
Closure to happen automatically on maturity
Period for processing is 10 days
Posting restriction code is 90

In this workshop, we will see how to create a Closure Product condition for closure on
maturity.
Closure to happen automatically on maturity
Period for processing is 10 days

Create a Closure Product condition for closure on balance becoming zero with the
following Settings:
Closure to happen automatically when all balances become zero
Period for processing is nil

In this workshop, we will see how to create a Closure Product condition for closure on
balance becoming zero .
Closure to happen automatically when all balances become zero
Period for processing is nil

The Eligibility Property Class helps in defining eligibility conditions for a customer to opt
for a product. Based on the rules defined for eligibility it would be decided whether or
not a customer can opt for a particular product. This is not a mandatory property class.

The Eligibility property defines the eligibility conditions for a customer to opt for a
product. Based on the rules defined here, eligibility of the customer for a product is
evaluated. The eligibility evaluation will be done at a given frequency or when there is a
static change at the customer. If the eligibility review process fails, the current product
will be moved to a default product. This property can be tracked and is date specific.

Banks require the ability to establish “eligibility requirements” for products. This can
apply to both “customer level” products (e.g. Relationship Pricing or Internet Services) as
well as traditional “financial” products (e.g. loans, accounts, deposits).
Eligibility checking enables:
The ability to specify eligibility criteria at the level of each product.
The ability to evaluate if a customer is eligible for a particular product.
Once an eligibility requirement has been established (e.g. available to residents over the
age of 18) system does the following:
For some products the eligibility requirement is checked only when the product is taken
out. For others the eligibility may be rechecked during the life of the arrangement and
customers who are no longer eligible (e.g. they are no longer resident) may need to be
moved to another product.

Eligibility criteria is defined at individual product level and is be based on customer

characteristics / attributes.
In the product designer it is specified whether the system would return an override or an
error.
If there are no rules defined, then the product is available for everyone.
If an eligibility evaluation fails, it results in an error or override.
For example:
Customer must be less than 18 (student)
Customer must be over 18, a local resident, full time employed
Customer must be a corporate local resident
Customer must be a foreigner (Non-resident)
Customer’s salary must be above 2M USD per annum

The eligibility requirements typically revolve around customer information such as:
Customer Type (e.g. Student, Staff, Resident, Non-Resident, Business), Relationship Value
(e.g. their total business with the bank), Relationship Length (i.e. how long have they
been a customer), Age etc.
Once an eligibility requirement has been established (e.g. available to residents over the
age of 18) the system does the following:
a) Filter the Product Catalogue to show only those products that the customer is
eligible for
b) Check the customer’s eligibility when trying to do the “New Arrangement” activity
Checking of eligibility requirement is carried out by the system:
a) When the product is taken out
b) When the primary customer changes
c) When there is a product change
d) Checked / Rechecked during the life of arrangement based on periodic review

The products that are offered to a Customer in Product Catalog are filtered based on
eligibility of the customer.
Subsequently, while creating an Arrangement, during Change Product and during Change
Customer the products are once again filtered based on eligibility.
For an eligibility review to happen either a periodic evaluation frequency can be set or a
change in customer static can trigger the eligibility review during the following close of
business. Can be set up at Product / arrangement level.
Once an eligibility review encounters failure, there are two possibilities:
a) Change Product – change product does not happen automatically. Change happens
to a ‘default’ product which will not have any Eligibility Rules of its own. This default
product is specifically marked with DEFAULT.PRODUCT flag at Product Designer level.
b) Ignore - this results in logging the failure on the arrangement. Available for view in
arrangement Overview.

Launch the T24 Toolbox by double clicking the icon. When the Toolbox is launched a
login screen will be presented.
Enter the correct user credentials and select the Sign on button. When the user
credentials have been verified select the Designers and Wizards menu item. When the
Designers and Wizards menu item is selected a number of icons are displayed. Launch
the Rule Designer by double clicking the icon. To create a new rule select the link in the
Actions column.

Enter the appropriate details in the ID and Description fields. Click Ok when details are
filled in. Enter the required details for your rule, ensuring that the appropriate Context
Rules are included. Once all required data is input select the validate icon, a successful
validation is illustrated in the example. Ensure that the Context quoted in the Rule
Designer is available to you in the Model Bank.

The Context quoted in the Rule Designer must be available in EB.CONTEXT and the rule
must be available in EB.RULES in Model Bank. Inputting EB.RULES.VERSION in the
command line will launch the EB.RULES.VERSION window; from the drop down select
the newly created rule.

Define the criteria in EB.RULES.VERSION. Inputting EB.RULE.GATEWAY in the command

line will launch the EB.RULE.GATEWAY window.
Enter the required data in the relevant fields. Commit the record and get it authorised.

In this example, a rule is created for customers who are staff. The steps for creating the
rule is shown. Finally, when, an attempt is made to open a Staff account for a customer
who is not eligible for the same, an error is encountered while committing the
arrangement.

Eligibility can be used for customer pricing. Here we have created two products. One is
the parent which has basic properties for creating and maintaining the account. The rest
of the properties which differentiate customer pricing are brought into the child product.

Creation of more such children, say Gold savings, Silver savings, Bronze savings, based on
difference in interest rate, salary of the customer helps in bringing in customer pricing.

Eligibility property helps us define eligibility conditions. However rather than assign a
single product to the customer, a choice of eligible products is given to a Customer,
under Single Customer View. Product eligibility definition is updated through ELIGIBILITY
Field in AA.PRODUCT.DESIGNER.
Routine(s) to validate eligibility would be run when making an enquiry or creating a new
arrangement. Eligibility updates result in display of product catalogue, as per the
customer’s eligibility. Products that the customer is not eligible for will not appear in the
catalog.
An Activity and associated Actions would evaluate and change product based on
eligibility. Eligibility review / update can be triggered by customer static change. The
evaluation can be done on a specified frequency or if there is any static change at the
customer level. During further evaluation, if any conditions fail, the current product is
moved to a default product.

Basic eligibility rules are defined in T24 rules engine, based on Customer attributes.
These are available under the drop down Basic eligibility rules. Can be multi-valued for
checking more then one eligibility factor. Failure of eligibility can be indicated through an
Error or Override. There are two options to review the failure action. It can be either
ignored or a change product can occur. Eligibility rules can be further drilled down to
check currency-wise for each product, which can be defined in the next row of Eligibility
Currency, Rules, failure type and failure action.
A periodic review can be scheduled by indicating the review frequency for checking the
eligibility of the customer for a product. Alternatively, based on changes in customer
attributes, a static review can be opted for. The eligibility review failure can result in
Change Product wherein, system picks out the Default product. A point to note is that
when defining the default product, eligibility PC is not included and the default product
marker in product designer is set to Yes. For subsequently created products, eligibility PC
contains the default product.


AALendingAdvancedPart3 PDF

Uploaded by

Document Information

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

AALendingAdvancedPart3 PDF

Uploaded by

Copyright:

Available Formats

AA Lending Advanced - Part 3

Temenos University - Novembre 2012 1

Temenos University - Novembre 2012 2

CHANGE.PRODUCT is an optional Property Class of LENDING Product Line. It can be used

Temenos University - Novembre 2012 3

Temenos University - Novembre 2012 4

CHARGE.TYPE Field defines if the charge amount is fixed amount or to be calculated

Temenos University - Novembre 2012 5

Temenos University - Novembre 2012 6

Temenos University - Novembre 2012 7

CALC.TYPE defines charge calculation type to be applied for charge calculations.

Temenos University - Novembre 2012 8

Temenos University - Novembre 2012 9

Charge minimums and maximums can be specified in two ways:

Temenos University - Novembre 2012 10

Temenos University - Novembre 2012 11

MIN.CHG.AMOUNT - For an arrangement, it is possible to specify minimum charge

Temenos University - Novembre 2012 12

Temenos University - Novembre 2012 13

Temenos University - Novembre 2012 14

Temenos University - Novembre 2012 15

Temenos University - Novembre 2012 16

CHANGE.PRODUCT is an optional Property Class of LENDING Product Line. It can be used

Temenos University - Novembre 2012 17

Temenos University - Novembre 2012 18

Temenos University - Novembre 2012 19

Temenos University - Novembre 2012 20

Temenos University - Novembre 2012 21

Temenos University - Novembre 2012 22

Create an Activity Charge Product condition with the following Settings:

Temenos University - Novembre 2012 23

Temenos University - Novembre 2012 24

Temenos University - Novembre 2012 25

Temenos University - Novembre 2012 26

Temenos University - Novembre 2012 27

Temenos University - Novembre 2012 28

Temenos University - Novembre 2012 29

Temenos University - Novembre 2012 30

Temenos University - Novembre 2012 31

Temenos University - Novembre 2012 32

Temenos University - Novembre 2012 33

An Activity Charges product condition is set up for new arrangement creation.

Temenos University - Novembre 2012 34

Charge product condition with 1% created for New Arrangement creation

Temenos University - Novembre 2012 35

Temenos University - Novembre 2012 36

An Arrangement is created for USD 100000, period of 1 year.

Temenos University - Novembre 2012 37

Temenos University - Novembre 2012 38

CHANGE.PRODUCT is an optional Property Class of LENDING Product Line. It can be used

Temenos University - Novembre 2012 39

Temenos University - Novembre 2012 40

Temenos University - Novembre 2012 41

Temenos University - Novembre 2012 42

Temenos University - Novembre 2012 43

Temenos University - Novembre 2012 44

Temenos University - Novembre 2012 45

Create a Charge Override Product condition with the following:

Temenos University - Novembre 2012 46

Temenos University - Novembre 2012 47

CHANGE.PRODUCT is an optional Property Class of LENDING Product Line. It can be used

Temenos University - Novembre 2012 48

Temenos University - Novembre 2012 49