AALendingAdvancedPart4 PDF

AA Lending Advanced Part 4
Temenos University - Novembre 2012 1


BALANCE.MAINTENANCE is an optional Property Class of LENDING Product Line. This

property class allows to capture bills, balances and adjust the balances of the bill for
those contracts which has been taken over from existing legacy system or existing T24
lending module into T24 AA module.
The action routines CAPTURE.BILL, ADJUST.BILL etc help in capturing the bill and its
balances into the new system.
LENDING-ADJUST.BILL-BALANCE.MAINTENANCE is an activity (class) for adjusting
balance / making the balance ‘0’.

This Property Class allows to capture bills, balances and adjust balances of bills taken
over from contracts.
Allowed values in Bill Type are PAYMENT, EXPECTED, ACT.CHARGE, PR.CHARGE, INFO ,
EXPECTED, DEF.CHARGE
The BALANCE.MAINTENANCE property class supports the following Types:
DATED,NON.TRACKING,CCY,MULTIPLE,ARRANGEMENT

Rules are set for Capturing Bills and Balances, Adjusting Bills and Balances and writing off
Bills and Balances. We will see these in the following slides.

This facility allows to manually capture existing bills in other legacy systems into AA
Module. Bills can be captured through CAPTURE.BILL activity.
Amounts by Properties, bill dates, bill due dates, total amounts, etc. need to be entered.
The bills should be dated before the date of creation of arrangement.
Once a bill is captured, further processing will be done as per product conditions.

Capture Balance is used to manually capture the unbilled balances (not yet become due)
from legacy systems in to AA.
Interest accrued, charges accrued can be captured before they become due or billed.
The value date should be before the start date of Arrangement


Balances captured can be adjusted. They can be increased or decreased or even adjusted
to Zero. It is possible to adjust more balances at a time in a single transaction.

Bill can be written of through write off bill activity.
This allows existing bills to be written off. When the bills are written off, the balances are
set to zero and the bills will be set to written off status.

Balances which are not related to Bills can be written of through Write off balance
activity. This allows balances to be written off. When the balances are written off, they
are set to zero and the status will be set to written off status.

This activity adjusts both billed and non billed balances. The bills vis-à-vis the balances
due and the balances not due can be adjusted in a single transaction. They can be
increased, decreased, even written off.

The recommended steps during migration are - Take-over Arrangement, Capture

outstanding Principal, Capture overdue Bills, Capture current accruals
• TAKE OVER ARRANGEMENT – Matured contracts having overdue payments in legacy
system can be taken over into T24 using the activity LENDING-TAKEOVER-
ARRANGEMENT. Similar activity class have been release for the Deposits and Savings
product lines as well. In the Takeover arrangement activity field
ORIG.CONTRACT.DATE is mandatory. This field is used to record the original value date
of the contract in the Legacy System. The field Amount in TERM.AMOUNT property
class must be set to zero for Take over arrangements. If it is a live contract in the
Takeover arrangement field Amount should have the contract outstanding amount.

• CAPTURE BALANCE– After the Takeover arrangement is created (Live contract

captured in T24) the balances in the CUR<Account> to be captured. Instead of
triggering the disbursement the activity LENDING-CAPTURE.BALANCE-MAINTENANCE
can be used to capture any balances. System will not allow the user to capture
suspended balances.
• CAPTURE.BILL - Like Capturing the balance there can be scenarios where we need to
capture bills from the Legacy System. In case of Loan we may have to take over the
overdue bill by using LENDING-CAPTURE.BILL-BALANCE.MAINTENANCE
• CAPTURE CURRENT ACCRUALS

User can initiate activities in every arrangement through Arrangement Overview > New
Activity Tab.

BALANCE.MAINTENANCE is an optional Property Class of LENDING Product Line. This

property class allows to capture bills, balances and adjust the balances of the bill for
those contracts which has been taken over from existing legacy system or existing T24
lending module into T24 AA module.
The action routines CAPTURE.BILL, ADJUST.BILL etc help in capturing the bill and its
balances into the new system.
LENDING-ADJUST.BILL-BALANCE.MAINTENANCE is an activity (class) for adjusting
balance / making the balance ‘0’.

PROPERTY.CLASS Field identifies which Property Class condition allows this periodic
attribute definition.
ACTION Field represents the valid ACTION for the Property Class.
COMPARISON.TYPE Field refers comparison types defined in EB.COMPARISON.TYPE file.
DATA.TYPE -This field represents the Valid Data Type. For example : AMT, PERIOD, R
(Rate), D (Date), A (Alpha), N (Numeric) and DAO (DEPT.ACCT.OFFICER). The attribute to
which the periodic rule is defined should have a data type specified so that the existing
core routines validate the rule content.
RULE.VAL.RTN Field represents a routine which returns the value for the comparison
routine to do the compare from property record. Should be valid entry in EB.API file.

PR.ATTR.CLASS Field identifies the Periodic Attribute Class to which the Periodic Rule
belongs to. Must be a valid AA.PERIODIC.ATTRIBUTE.CLASS Id.
PERIOD.TYPE Field represents rule that needs to be applied on a specific period or life
time of Arrangement. Possible values are:
LIFE – Restriction applies to entire life of Arrangement;
INITIAL – Restriction applies to an initial period only of an arrangement during its life;
REPEATING - Restriction applies for a fixed repeating period during life of an
arrangement (e.g. every 3 month period say April to June);
ROLLING – Restriction applies for a rolling period that ends at date of transaction (e.g.
Maximum repayments in last three months).
PERIOD Field represents exact period to define for the Rule.
If DATE.TYPE is set to Calendar, then this field should be in 'Y'(years) or 'M' (months).
Accepted values are :
nnM or nnY or nnD or nnW (For Example : 01D, 12M )

RULE.START Field represents start date of the period defined. Possible values are:
AGREEMENT – Effective start Date of the Product; ARRANGEMENT– start date of lending
Arrangement;
START – Date of the First disbursement in Arrangement; if not disbursed, then the
arrangement start date will be taken till it is disbursed
ANNIVERSARY - takes the date and month from the field anniversary in ACCOUNT
property class; not valid for Period Type – Life and Initial;
COOLING-OFF - takes the cooling date from Term Amount property as the base date for
calculating the periodic restriction.
(Eg. Cooling period ends on 31st Dec. 2010, periodic restriction is set for
AMOUNT.INCREASE and the period is set to 1 year when RULE.START is set to COOLING-
OFF, then periodic restriction will apply from the end date of cooling period and not
from the date of arrangement.)
Any charges that need to be collected during pre-closure of Loan can be controlled using
COOLING-OFF period.
A sample of a periodic attribute configured for this would be: PERIOD.TYPE>LIFE;
RULE.START>COOLING-OFF
The above definition would charge the customer if any pre-closure is triggered after the
cooling period.
RULE.ERR.MSG Field represents error message that needs to be raised when the rule is
broken. Should be a valid record Id of the file EB.ERROR.
RULE.OVE.MSG Field represents override message that needs to be raised when the rule
is broken. Should be valid record Id of the file OVERRIDE.

The file AA.PERIODIC.ATTRIBUTE.CLASS is released by Temenos. This file will contain

standard rule definitions.
This table will contain the definitions of
•property class that it can be linked to
•the comparison type to be used
•the action that should trigger this rule to be validated
•the value routine used to derive the data values to be compared as part of the
validation

AA.PERIODIC.ATTRIBUTE file contains the Period level definition. This file allows the
user to create records which has specific period definition in them.

PERIOD.TYPE field represents the rule that needs to be applied on a specific period or life
time of the contract.
Options are:
LIFE – Restriction applies for the entire life of an arrangement or arrangement life as a
certain product.
INITIAL – Restriction applies for an initial period only of an arrangement during its life
time or the initial period of an arrangement as a certain product.
REPEATING – Restriction applies for a fixed repeating period during either the life of the
arrangement or the life of an arrangement as a certain product. For example the
restriction may be based on a 12 a month calendar period (i.e. Jan to Dec) or a 3 month
period starting on the anniversary of the loan,
ROLLING – Restriction applies for a rolling period that ends at the date of a transaction.
For example the maximum repayment in the last three months.

PERIOD field represents the exact period the user wants to define for the Rule.
Validation Rules :
No input if
1) the PERIOD.TYPE is INITIAL or
2) RULE.START is ANNIVERSARY
Mandatory input otherwise. If DATE.TYPE is set to Calendar, then this field should be in
'Y'(years) or 'M' (months).

CALENDAR - This denotes if the rule is applicable for Calendar period or not. When set to
Calendar, Rule Start will be applied from the calendar start date of the month or year as
specified.
Other set up to support Calendar type are:
1) PERIOD - should be in 'Y', or in 'M'
2) PERIOD.TYPE - should be either INITIAL or REPEATING.
E.g.
Arrangement Start - 20070601
RULE.START - ARRANGEMENT
PERIOD - 12M
PERIOD.TYPE - REPEATING
Then the Start & End dates of the Rule when the Effective Date is 20071001 is
Start Date : 20070601(Actually it should be 20070101 - since arrangement start date
falls later, this date is taken)
End Date : 20071231 (ends on calendar end date)
and when Effective Date is 20080201,
Start Date : 20080101
End Date : 20081231 (ends on calendar end date)

RULE.START - This field represents the base date which is to be taken for computing the
periods.
Mandatory Input field.
• AGREEMENT - takes the current Product's Effective date as the base date.
• ANNIVERSARY - takes the date and month from the field anniversary in the property
corresponding to ACCOUNT property class. This is not a valid input for the
PERIOD.TYPE - LIFE.
• ARRANGEMENT - takes the start date of the Arrangement

• START - takes the first disbursement date as the base date. If not disbursed, then the
arrangement start date will be taken till it is disbursed.
• COOLING.PERIOD - Takes the cooling date as the base date for calculating the
periodic restriction (Eg. If the cooling period ends on 31st Dec. 2010, periodic
restriction is set For AMOUNT.INCREASE and the period is set to 1 year when
RULE.START is set to COOLING.PERIOD, then periodic restriction will apply from the
end date of cooling period and not from the date of arrangement).

RESTRICTION - Provides another layer for restriction to the Rule. By default, the rule is
applicable for the specified period mentioned in RULE.START. Optionally the user could
input this field to restrict the period further by defining a start period & end period
within the period(defined in PERIOD) between which the Rule is applied.
Input must be like nnnT-mmmT, where nnnT & mmmT should be a valid Period Type
with the exception of allowing 0.
E.g: 0D-1D, 0M-1M; 1M-12M;
Arrangement Start - 20070601
RULE.START - ARRANGEMENT
PERIOD - 12M
PERIOD.TYPE - REPEATING
RESTRICTION.PERIOD- 0M-1M
DATE.TYPE - NULL
The rule is applied only for 1M from 01-June every year.
RULE.START.PERIOD - This field represents the start period from when the rule is
applicable. The actual start date is calculated based on RULE.START definition.
RULE.END .PERIOD- This field represents the end period until when the rule is applicable

Controlling Attribute values of an Arrangement over a period of time is done by Periodic

Rules, which in turn depends on Periodic Attributes. Let us try to understand linkages
between various components related to Periodic Attributes.
Top-level component to control Attribute values over a period is the Periodic Attribute
Class. These are not Property Classes, but can be used to control other Property Classes.
They are defined by Temenos. They are linked to EB.COMPARISON.TYPE records and
routines to evaluate Attribute values updated in an Arrangement. A Periodic Attribute
can act on the Attributes of a specified Property Class.
Periodic Attributes can be defined by Users by combining a time element with a Periodic
Attribute Class.
Finally, User can attach the Periodic Attributes to a Product Condition. While attaching a
Periodic Attribute to a Product Condition, User has to specify a comparison value for
evaluation and can optionally specify a Break Result and Break Charges. Whenever the
Attributes of the Property Class are updated in an Arrangement, the Periodic Attributes
will be evaluated. The Break Result is used to tell the system how it should behave when
the Periodic Attribute fails and how much has to be charged for such failure.

MAXIMUM.RATE: Checking the maximum legal rate of interest, generating an override /

error when rule is violated.
MINIMUM.RATE: Checking the minimum rate of interest, generating an override / error
when rule is violated.
RATE.DECREASE : Checking the decrease in rate of interest
RATE. DECREASE.TOLERANCE - Checking the percentage decrease in rate of interest
RATE. INCREASE - Checking the increase in rate of interest
RATE.INCREAS E.TOLERANCE - Checking the percentage increase in rate of interest
MAXIMUM.CHARGE – Checking the maximum charge for a product
MINIMUM.CHARGE - Checking the minimum charge for a product

Set a Periodic Attribute for tolerance of decrease in Interest Rate during any 1 year
period. Rule to be applied from effective of arrangement.

In this workshop, we are going to create a Periodic attribute with the following Settings:
Set a Periodic Attribute for tolerance of decrease in Interest Rate during any 1 year
period.
Rule to be applied from effective of arrangement.

Term Amount Property Class:

• AMOUNT DECREASE - Used to restrict the maximum amount that the committed
principal can be decreased by over a specified period of time. The rule is validated
when a DECREASE activity takes place on the TERM.AMOUNT Property. Amounts are
compared from the AMOUNT field in the TERM.AMOUNT property. The PR.VALUE
value must specify the maximum decrease AMOUNT.
• For example a rule could be specified that specifies a maximum decrease in principal
of 1,000 is allowed over a 6 month period.
Committed amount 6 months ago 20,000
Allowed decrease in 6 month period is 1,000
If the new AMOUNT is less than 19,000 the rule will be broken.
• AMOUNT DECREASE TOLERANCE - the rule specifies the percentage decrease allowed
over time rather than a specific amount. The percentage decrease is calculated as the
percentage of the value at the start of the restriction period. The rule is validated
when a DECREASE activity takes place.
The PR.VALUE value must specify the maximum decrease PERCENTAGE.
• For example a rule specifies that a 5% decrease is allowed over a 6 month period.
Available balance 6 months ago 10,000
Allowed decrease in the 6 month period is 5% of 10,000 = 500
If the new AMOUNT value in the property is less than 9,500 the rule will be broken.
AMOUNT INCREASE - Periodic Rule to control increase in Principal Amount.

AMOUNT INCREASE TOLERANCE - Periodic Rule to control percentage increase in

Principal Amount.
FULL.DISBURSE - Periodic Rule controls disbursal of Commitment
Amount

• AMOUNT INCREASE - restrict the maximum amount that the committed principal can
be increased by over a specified period of time. The rule is validated when an
INCREASE activity takes place on the TERM.AMOUNT property. Amounts are
compared from the AMOUNT field in the TERM.AMOUNT property.
The PR.VALUE value must specify the maximum increase AMOUNT.
• For example a rule could be specified that specifies a maximum increase in principal
of 1,000 is allowed over a 6 month period.
Committed amount 6 months ago 20,000
Allowed decrease in 6 month period is 1,000
If the new AMOUNT is more than 21,000 the rule will be broken
• AMOUNT INCREASE TOLERANCE - rule specifies the percentage increase allowed over
time rather than a specific amount. The percentage increase is calculated as the
percentage of the value at the start of the restriction period. The rule is validated
when an INCREASE activity takes place.
• For example a rule specifies that a 5% increase is allowed over a 6 month period.
The PR.VALUE value must specify the maximum increase PERCENTAGE.
Available balance 6 months ago 10,000
Allowed increase in the 6 month period is 5% of 10,000 = 500
If the new AMOUNT value in the property is more than 10,500 the rule will be broken.
• FULL.DISBURSE - Allows control of whether partial disbursement is allowed. A value of YES

will specify that when the arrangement is disbursed all committed principal for the effective
date of the disbursal should be disbursed

Set a periodic attribute for decreasing commitment amount during the first year of
arrangement, starting from arrangement date and
Set a periodic attribute for full disbursement for life of the product, starting from
product effective date

In this workshop, we are going to create a PERIODIC.ATTRIBUTE with the following

Settings:
Set a periodic attribute for decreasing commitment amount during the first year
of arrangement, starting from arrangement date
Set a periodic attribute for disbursement amount for life of product, starting from
product effective date

ACTIVITY.RESTRICTION is an optional Property Class of LENDING Product Line. It can be

used to restrict certain Activities. Please recollect that an Activity is an instance of an
Activity Class and that it is related to a Property.

ACTIVITY.RESTRICTION Property class is DATED, CCY, TRACKING and MULTIPLE Types.

It is possible to have more than one instance of a ACTIVITY.RESTRICTION property class.
The TYPE FORWARD.DATED in the PROPERTY.CLASS controls and allows the user to
introduce a new definition at the arrangement level, it will be dated

It is possible to restrict an Activity in full, wherein the Activity cannot be run altogether.
Prevent an Activity from occurring by restricting the activity – LENDING-
CHANGE.PRIMARY-CUSTOMER, LENDING-CHANGE.PRODUCT-ARRANGEMENT. The
activity being restricted must be a valid activity under AA.ACTIVITY. The restriction could
pertain to e.g. Not to allow change of Customer, not to permit change of Product, not to
allow change in Interest rate, not to permit repayment/Prepayment in loan account
below the prescribed minimum amount, not to allow prepayments beyond a maximum
transaction amount etc. Partial or conditional restriction is also based on Activities. The
activity is permitted, with an Override or additionally, with a charge.
The partial restriction could mean e.g. Allow Disbursement in loan Account, but only in
multiples of 100, Allow more than 12 repayments in loan Account in a period. This is
achieved by linking periodic rules to the ACTIVITY.RESTRICITON Product Conditions.

Activity restrictions can be defined based upon the activity itself (number or count of
activities or amount of the activity) or based on the balances that are affected by this
activity (minimum balance requirements).
Balance Rules – when activity restriction rules are based on balance types, whenever an
activity is triggered, it can be specified to check a balance and further assign a charge if
the rule is broken. E.g. Minimum balance requirements in an Account etc.,
Transaction Rules can be of two types. Transaction amount based and Transaction count
based.
When the activity rules are based on transaction amount, whenever the activity occurs,
the transaction amount rules are checked. A charge can be assigned if the rule is broken.
E.g. Transaction amount must be in multiples of 500, Prescribe Minimum transaction
amount for Prepayment of loan Account etc. When the activity restriction rules are
based on transaction count, and the activity is triggered, the transaction count rules are
checked. A charge can be assigned if the rule is broken. E.g. Repayments in loan Account
cannot exceed 12 in a year, 2 Prepayments in loan account is generally permitted, any
extra Prepayments would attract a charge.

It is possible to place restrictions on Interest and Periodic Charge properties defined in

Payment schedule product condition. These restrictions can be based on the transaction
count / based on the transaction amount of the activity / based on the balances that the
restrictions affect (e.g. minimum balance or maximum balance).
When an activity restriction rule is broken, there are 2 options available:
a) To waive the Interest or Periodic Charge Property amount and apply an alternate
Interest or Periodic Charge Property if it has been defined. Or
b) To apply the actual Interest amount and ignore the alternate Interest that has been
defined.
If the activity restriction rule is not broken, the available options are:
a) To waive the Interest or Periodic Charge Property amount and apply an alternate
Interest Charge Property, if defined. Or
b) To apply the actual Interest amount and not to apply alternate Interest.
The rule based restriction helps in regulating the processing of properties – both Interest
and charges – and provide alternate properties. When an activity restriction rule is
broken, penalty interest can be used as alternate property. Again when the rule is
satisfied, a better rate of Interest (bonus) can be provided with an alternate Interest
property.

The property activity restriction has three sets of fields to define restrictions based on
the Activity itself or on the balance types that the activity affects.
a) Rule based fields b) Activity based fields c) Property based fields. The rule based
restrictions could be imposed at the time of the activity being triggered or at the time
when a property like interest or charge defined in the payment schedule is processed or
during close of business.
Rule based fields– rules created to impose restrictions on activities. It is possible to
create as many rules as desired in an arrangement in the same record. Next, Activities
are attached to these rules which are defined in activity based fields.
Activity based fields – activity that needs to be restricted is defined here. The rule
created earlier in the rule based field is attached to the activity. An override as desired is
also defined here.
Property based fields - Properties like interest and charge that are set to be processed in
a defined frequency (as defined in payment schedule) can be restricted and regulated
based on the defined rules. The rule created earlier in the rule based field is attached to
the property. An override as desired is also defined here.

RULE.NAME : When a rule is created, a name is given to the rule for later use. A
meaningful name can be given.
As desired, any number of rules can be multi-valued.
PERIODIC.ATTRIBUTE: This field should contain a valid record from
AA.PERIODIC.ATTRIBUTE. Periodic attributes are explained

ACTIVITY.CLASS / ACTIVITY : The activity class or the activity on which the restriction is to
be imposed. Any valid AA.ACTIVITY may be stated here.
BALANCE: The balance type on which the rule should apply.
VALUE: The amount of the balance type for which the rule is defined.

ACTIVITY.CLASS / ACTIVITY - The activity class or the activity on which the restriction is to
be imposed. Any valid AA.ACTIVITY may be stated here.
RUN.THE.RULE – The rule created in the earlier rules tab is attached to the Activity by
input of rule in this field.
BREAK.RESULT – Options can be Error / Override. Depending on complete or partial
restriction, the appropriate option is to be chosen.
ERROR - The transaction triggering this activity would be completely blocked. If
transaction is completely blocked, it is mandatory to choose an error message displaying
restriction. Should be a valid entry in EB.ERROR table.
OVERRIDE - The transaction triggering this activity would be allowed after displaying a
warning. If the transaction is to be allowed after displaying a warning, it is mandatory to
state an override message. Should be a valid entry in OVERRIDE table.

CHARGE.PROPERTY - This field denotes the charge property which will calculate charge
amount when a rule is broken. Only charge property can be input in this attribute.
PR.APP.PERIOD – The application period for the given periodic rule charges is input here.
If the value defined is zero, then the charges are applied immediately.
PR.APP.METHOD - field denotes the application method that needs to be applied to the
rule break charges. Allowed values are
Due - Rule break charges are made due
Capitalise - Rule break charges are capitalised
Defer - Rule break charges are calculated but not applied immediately. Charge are
deferred and are collected over a period of time. Collection of these deferred charges is
driven by payment schedule and Periodic charges property classes

PROPERTY: The Interest or (periodic) Charge property scheduled as per definition in

Payments Schedule Property.
RUN.THE.RULE : The rule created in the earlier rules tab is attached to the Property by
input of rule in this field.

EVALUATION: When an activity restriction rule is broken, there are 2 options available.
Breaking the rule or Satisfying the rule. E.g. Penalty interest can be used for breaking the
rule and Bonus interest (a better rate of Interest) can be used for satisfying the rule.
EVALUATION.RESULT: This has two options.
a) To waive the Interest or Periodic Charge Property amount
b) To apply the actual Interest / charge amount
ALTERNATE.PROPERTY: When the evaluation result options is ‘waive’ an alternate
property can be chosen for Interest / charge.

TRANSACTION AMOUNT MAXIMUM - restrict the maximum AMOUNT allowed for the
Activity for any single activity. The amount of the activity is assumed as the
TXN.AMOUNT in the AA.ARRANGEMENT.ACTIVITY record for the current activity
being processed. The PR.VALUE must specify the maximum AMOUNT allowed
TRANSACTION AMOUNT MINIMUM – restrict the minimum AMOUNT allowed for the
Activity for any single activity. The amount of the activity is assumed as the
TXN.AMOUNT in the AA.ARRANGEMENT.ACTIVITY record for the current activity
being processed. The PR.VALUE must specify the minimum AMOUNT allowed.

TRANSACTION AMOUNT MULTIPLE – restrict the amount of an activity to be in

multiples specified as the associated PR.VALUE. For example if disbursal is only
allowed in multiples of 5,000 a rule value of 5,000 should be defined. Processing will
validate that the current activity amount is a multiple of the defined amount.
TRANSACTION AMOUNT TOTAL – restrict the maximum TOTAL AMOUNT for an
activity over a specified (defined in AA.PERIODIC.ATTRIBUTE). Processing will
determine the total amount processed within the defined period to date and will
calculate and verify if the current activity request is within the specified maximum
value. If it is not either an error or override message will be generated. The PR.VALUE
must specify the maximum total AMOUNT for the activity allowed within a period.

TRANSACTION COUNT TOTAL - restrict the number of activity over a specified period.
The Maximum number of transactions allowed in a period is defined in the associated
PR.VALUE. Processing will determine the current count of activities of the current type
requested in the processing period and will validate that an additional activity is
within the allowed number. PR.VALUE must specify the maximum NUMBER of
Activities allowed within a period.

CURR.LOAN.REPAY.TOLERANCE - restriction to control repayment amounts by

comparing the repaid amount as a percentage of the available loan balance at the
start of the restriction period. The periodic attribute will be validated when a
repayment is made against the loan. The periodic rule will be linked to an activity of
the LENDING-APPLYPAYMENT-PAYMENT.RULES class.
The processing will take the current committed loan balance at the calculated period
start, calculate the percentage, and
compare this with the total repayment in the period.
TOTAL.LOAN.REPAY.TOLERANCE - attribute class is similar to

CURR.LOAN.REPAY.TOLERANCE but will provide a restriction to the repaid amount as a
percentage of the total committed loan balance at the start of a given period.
The periodic attribute will be validated when a repayment is made against the loan.
The periodic rule will be linked to an
activity of the LENDING-APPLYPAYMENT-PAYMENT.RULES class. The processing will
take the total committed loan balance at
the calculated period start calculate the percentage, and compare this with the total
repayment in the period.

An example for Activity restriction with Periodic attribute (Time element) is shown here.

Step 1: Since it is an Activity Restriction , choose a periodic attribute which will suit
this requirement
Step 2: Since this is somewhat related to the frequencies, the ideal periodic
attribute will be Transaction Count Total
Step 3: Create a Periodic Attribute under that Periodic Attribute class with a
PERIOD.TYPE – INITIAL , PERIOD – 1Y,
RULE.START – ARRANGEMENT

Attach the periodic attribute created in the ACTIVITY.RESTRICTION product condition

under the Tab - Rules

Specify the activity that needs to be restricted and indicate whether an error or override
message to be displayed if the rule is broken and optionally a charge property can be
attached which will be triggered if the rule is broken.

Attach the Product condition created for activity restriction in the product designer and
proof and publish it. Since we have attached a rule break charge property
“PRINDECREASEFEE” whenever the rule is broken, attach a valid product condition for
that charge property.

Now create a new arrangement for your customer for the product created earlier.

After authorising the arrangement, we are making a disbursement to the customers

account.

When we try to do a prepayment within a period of one year system is giving us a

warning/Override message.

Set a Periodic Attribute under Activity Restriction Property Class for restricting the
Disbursement Amount in Multiples of USD 1000.

Set a Periodic Attribute under Activity Restriction Property Class for restricting the
Disbursement in Multiples of USD 1000
In the periodic attribute set the following:
Rule to be applied for Life of the arrangement
With effect from start date of arrangement

Create a new Product Condition for ACTIVITY.RESTRICTION with the following Settings:
Set the rule to restrict Disbursement in Multiples of USD1000
(LENDING-DISBURSE-COMMITMENT)
Attach the periodic attribute created in the Previous workshop
(ACTIVITY.RESTRICTION-Periodic Attribute)
If user attempts to break the rule Error message to be displayed,
All Attributes are not negotiable by default.

In this workshop, we will see how to create an Activity Restriction Product condition.
Set the following Conditions:
Set the rule to restrict Disbursement in Multiples of USD1000
(LENDING-DISBURSE-COMMITMENT)
Attach the periodic attribute created in the Previous workshop
(ACTIVITY.RESTRICTION-Periodic Attribute)
If user attempts to break the rule Error message to be displayed,
All Attributes are not negotiable by default.


You have learnt earlier that a Property Class is a fundamental building block of AA and
that a Product Line is a combination of Property Classes. Property Classes and Product
Lines are released by Temenos and you can only amend their Description.

The Product Line provides a high level definition of the business components (Property
Classes) that may be required to construct a product belonging to that line. For example
the LENDING Product Line will enable users to design and service term loan products
such as Loans (personal, small business, etc.) Mortgages Lines of Credit.
The Product Lines are defined by Temenos and cannot be created by the User. A Product
Line is described by the Property Classes which constitute it. The financial institution
may then use these “building blocks” of functionality to construct the individual
products which are available for sale to its customers.

LINE.ATTRIBUTE: This optional field is used to specify whether the product line deals
with amounts/currencies and Reverse and Replay functions are allowed. This field for
lending product line contains a value CCY and REPLAY. Values possible are CCY, REPLAY
and NULL.
MANDATORY field identifies whether inclusion of a Property a Class in the associated
multi value field PROPERTY.CLASS is mandatory when creating a new product in
AA.PRODUCT.GROUP and subsequently, AA.PRODUCT.DESIGNER.

We will look into how you can design a AA Product beginning with Product Group.
Please recollect that the Product Group is in the second level of Product organisation.
Product Line in the first level can be defined only by Temenos. Users can create their
own Product Group under existing Product Lines. Each Product Group has a number of
Properties associated with it and specified as Mandatory or not. Each Product Group
must have one Mandatory Property for each of the mandatory Property Classes of its
Product Line. All Products belong to a Product Group.

GROUP.TYPE Field : Valid options are INTERNAL and EXTERNAL.

INTERNAL – means the group being defined is own Bank's product. Only products
specified as INTERNAL are available for sale to customers.
EXTERNAL - There may be a necessity for Banks to do comparison between its own
product(INTERNAL) and one by its competitor. Those groups may be defined as
EXTERNAL. These products may then be used for comparitive analysis to show the
superiority of Bank's own product. Products of this type are not available for sale to own
customers.
REBUILD.ACTIVITIES Field is used to rebuild AA.ACTIVITY records from
AA.ACTIVITY.CLASS. AA.ACTIVITY is an instance of AA.ACTIVITY.CLASS, records would be
created on AA.ACTIVITY for all instances (properties) of class (property class) at
authorisation stage. This can be used to rebuild activities when a new property is
introduced into a group.

Create a new Product Group

In this workshop, we will create a Product group created by using the existing properties
attached to the Property Class with properties marked as Mandatory or optional.


INHERITANCE.ONLY : T24 product builder follows a structured way of defining products.

In addition to this structural hierarchy, the Product Builder enables the definition of “fam
ilies” of products through Product Inheritance.
This allows for a derivative of a product to be defined by simply
specifying a “parent” product and any different conditions.
Inheritance Only products do not undergo full proofing validations nor are they available
for sale on their own. They are only abstract definition of a product which should be
derived down the hierarchy to define the product in its entirety.

EFFECTIVE Field represents the effective period after which the new property condition
comes into effect. In addition to dated changes of a single Defined Property, the Product
designer also allows a Product to be defined with “timed” changes of its conditions.
These timed changes may be defined as “condition changes” (i.e. a standard product
property is linked to one Defined Property and after a period of time switches to a
different Defined Property.

CURRENCY field indicates the currency(ies) that are possible within this product. The
input must be a valid record from the CURRENCY table.
This is a multi value field.

CALC.PROPERTY: Some properties require calculations for them. For example, a Current
Interest property may have to accrue interest at a specific rate on a specified amount.
The base amount on which such calculations should happen is stated here. The field is
associated with SOURCE.TYPE, SOURCE.BALANCE.
The property stated here would be validated in the proofing stage to verify if they
actually belong to this product.

Create New Product available in USD with existing Product conditions or new product
conditions.
Note : For the Properties marked with red one use the existing product conditions given
in the workshops.

In this workshop, we will create a Product by attaching a Product Condition to each of

the Properties that were used in the product group created earlier.
Note : Product Conditions can be existing ones or new ones that were created in the
previous workshops

In this workshop, we will create a Product by attaching a Product Condition to each of

the Properties that were used in the product group created earlier.
Note : Product Conditions can be existing ones or new ones that were created in the
previous workshops


Set the Calculation source for PRINCIPAL INTEREST and make the Product Available in
USD

A Product in AA goes through three processes – Product designing, proofing and

publishing.
Designing is the Process of creating Products and attaching Product Conditions to their
Properties. It is done using the T24 Product Browser.
When a Product is designed, it has to undergo Proofing process. Proofing validates that
the Product has been configured correctly without errors, and is ready for release.
Proofing is the process that checks whether the Product is in sync with its hierarchy such
as Parent and or the associated Product Group.
Once a Product is proofed, it has to be published. Publishing is the process by which a
Product is put into Product Catalog. Once a Product is published into Product Catalog, it
is available for sale. When a parent Product is proofed and published, these functions
are performed down the line to all the child Products under it. In this case it is not
necessary to individually proof and publish the child Products.
New Arrangements can be created only for a Product published into Product Catalog.
Products are proofed and published through AA.PRODUCT.MANAGER Application.

The above diagram defines a line between proof and publish.

We have seen how Product Designer allows you to create Products with their Properties
and Conditions.
The next stage is Proofing. At the proofing stage, we need to set the available date of the
product. This will allow you to enter the Product into the catalog in advance of it going
on sale.
Proofing then validates that the Product has been configured correctly, and is ready for
release. Proofing includes for example checking whether all mandatory Properties have
been given conditions, that there are no conflicts between those conditions, and any
other errors that would prevent the Product being published.
Any errors generated can be fixed by going back to the Product Designer, and then re-
proofing the product.
When the Product is published, it is entered into the Product Catalog, which is the tool
used to actually create Arrangements.
Once published, Products can be modified at any time. Modification is done in the
Product Designer, using the same method as for creation. Modifications will only appear
in the Product Catalog once the proofing & publishing process has been repeated.

When you proof and publish a product through AA.PRODUCT.MANAGER, you have to
define two dates related to it.
One is the Available Date, which is the date from which the Product is available for sale.
Only from this date, Arrangements for the product can be created. AVAILABLE.DATE Field
is used for this.
Another one is the Expiry Date, from which the Product will cease to exist and no
Arrangements can be input for the Product. However, existing Arrangements for the
Product will continue. EXPIRY.DATE Field is used to mention the expiry date of product.
PRODUCT.ERROR Field in displays the errors caused when Proofing fails.
SUGGESTION Field displays suggestions for rectifications of errors.

Proof and Publish the Product

In this workshop, we are going to Proof the product created

And Publish it.

Create New Arrangement

In this workshop, we are going to create the arrangement for the product published in
the previous workshop in USD for your Customer

Look at the defaulted Term and amount of Arrangement. Is it as per your

condition set in Product designer
Change the term to 1Y and amount to 100,000.

Look at the PAYMENT.SCHEDULE and INTEREST property. Are the values defaulted as per
your Payment Schedule and Interest Product conditions

Look at the Settlement instructions and input the Payin Activity with T24 Account or
Arrangement Account
Commit the Arrangement and accept the overrides
Notice that a charge for New arrangement (NEWARRFEE) is made due

Now select the customer for whom the arrangement was created under the
unauthorised tab and authorise the arrangement created.

Authorise the Arrangement

View the Payment Schedule

Disburse the Loan to your Customers current Account in USD and authorise it.

In this workshop, we are going to Disburse the Arrangement created

Disburse USD 100,000 to Customer’s Current account in USD
Approve Overrides and authorise it

After authorising the disbursement, view the Status of the Arrangement changed to
Current, Financial Summary and the Activity log.




AALendingAdvancedPart4 PDF

Uploaded by

Copyright:

Available Formats

You might also like

AALendingAdvancedPart4 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

AALendingAdvancedPart4 PDF

Uploaded by

Copyright:

Available Formats

AA Lending Advanced Part 4

Temenos University - Novembre 2012 1

Temenos University - Novembre 2012 2

BALANCE.MAINTENANCE is an optional Property Class of LENDING Product Line. This

Temenos University - Novembre 2012 3

Temenos University - Novembre 2012 4

Temenos University - Novembre 2012 5

The bills should be dated before the date of creation of arrangement.

Temenos University - Novembre 2012 6

The value date should be before the start date of Arrangement

Temenos University - Novembre 2012 7

Temenos University - Novembre 2012 8

Temenos University - Novembre 2012 9

Bill can be written of through write off bill activity.

Temenos University - Novembre 2012 10

Temenos University - Novembre 2012 11

Temenos University - Novembre 2012 12

The recommended steps during migration are - Take-over Arrangement, Capture

Temenos University - Novembre 2012 13

• CAPTURE BALANCE– After the Takeover arrangement is created (Live contract

Temenos University - Novembre 2012 14

Temenos University - Novembre 2012 15

BALANCE.MAINTENANCE is an optional Property Class of LENDING Product Line. This

Temenos University - Novembre 2012 16

Temenos University - Novembre 2012 17

Temenos University - Novembre 2012 18

Temenos University - Novembre 2012 19

The file AA.PERIODIC.ATTRIBUTE.CLASS is released by Temenos. This file will contain

Temenos University - Novembre 2012 20

Temenos University - Novembre 2012 21

Temenos University - Novembre 2012 22

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

Controlling Attribute values of an Arrangement over a period of time is done by Periodic

Temenos University - Novembre 2012 28

MAXIMUM.RATE: Checking the maximum legal rate of interest, generating an override /

Temenos University - Novembre 2012 29

Temenos University - Novembre 2012 30

Temenos University - Novembre 2012 31

Term Amount Property Class:

AMOUNT INCREASE - Periodic Rule to control increase in Principal Amount.

Temenos University - Novembre 2012 32

AMOUNT INCREASE TOLERANCE - Periodic Rule to control percentage increase in

Temenos University - Novembre 2012 32

• FULL.DISBURSE - Allows control of whether partial disbursement is allowed. A value of YES

Temenos University - Novembre 2012 33

Temenos University - Novembre 2012 34

In this workshop, we are going to create a PERIODIC.ATTRIBUTE with the following

Temenos University - Novembre 2012 35

ACTIVITY.RESTRICTION is an optional Property Class of LENDING Product Line. It can be

Temenos University - Novembre 2012 36

ACTIVITY.RESTRICTION Property class is DATED, CCY, TRACKING and MULTIPLE Types.

Temenos University - Novembre 2012 37

Temenos University - Novembre 2012 38