T3TAAD-Arrangement Architecture Deposits

1
T24 Arrangement Architecture -Deposits -

T3TAAD - R18 1
2
T3TAAD – Arrangement
Architecture - Deposits
NOTICE
Copyright © 2010 - Present- Temenos Headquarters S.A. All rights reserved.

All content and images contain herein are copyright protected and are the property of Temenos Headquarters S.A. and/or its affiliates. You may
not reproduce, modify, distribute or republish materials contained in these materials (including by framing or similar means) without prior written
permission. You may not alter or remove any trademark, copyright or other notice from these materials. Any rights not expressly granted herein
are reserved.

T3TAAD - R18 2
Learning Objectives
Arrangement Architecture - Deposits - Objectives 3
Objectives • Introduction to Deposits Product Line

and Property Classes
• Setup parameter tables, create Property

and Product conditions for Deposits
Product Line
• Create Deposits Product Group and

Product, proof and publish the product
• About Deposits activities, Simulation
• Enquiries relevant to this module
• Viewing the features of a Savings plan

product
• Variation Product for Deposits
The AA Deposits Product Line provides a flexible framework that allows new
deposit products to be created. This provides a business component based
architecture for the management of deposit products.
DEPOSITS Product line which provides functionality for different banking
areas is licensed by Temenos; The Deposits Product line utilises a number of
property classes (business components).
In this course, we will be looking at creating properties and product conditions,
building families of products, inherit properties from the product family
structure.
We will be creating default values to be applied for product arrangements like
dated conditions for products, or negotiation between product and arrangement
conditions either partly or in full. We will then Design/Proof/Publish the
product.

T3TAAD - R18 3
4 4
Overview - Retail
Deposits
Overview – Retail Deposits

T3TAAD - R18 4
Learning Objectives 5
Objectives  In this learning unit let us have a
 Basic overview of AA Deposits
Core Dependencies
 Quick recap of property class type and

property type with product conditions
Learning Objectives

T3TAAD - R18 5
AA Deposit Arrangement – Product overview 6
Calculated
Amount
Periodic
payment Fixed
Floating
Actual
Arrangement Amount Periodic
AA
Deposits Bullet
payment
Payment
Schedule
Arrangement is an agreement between the bank and interested party to provide

an agreed service. AA module provides ability to create and manage
arrangements for customers. AA Deposits support repayment of principal and
interest during the deposit period or Interest during the deposit period and
Principal at the end in one shot.
Redemptions could be either calculated or user defined.
T24 allows fixed, floating or a banded mix of fixed and floating interest rates for
AA Deposits.
AA Deposits provide basic functionalities like Opening and closing of Deposits
Arrangement in AA. Deposits arrangement is a record created from the
associated Deposits product.

T3TAAD - R18 6
AA Deposits – Product overview 7
Arrangement
Conditions
Arrangement
Negotiable
Deposit
Non Account
Deposit Negotiable
Product
Conditions
Bills for
payment
Tracking
Fund
Cancel
Deposit
Non Tracking Period
Account
Cancel /
Cooling Off
Pending
Period
closure
Closure on
Maturity / Closure
Earlier
The conditions set for the associated Deposits Product are defaulted into the
Arrangement when created. User can negotiate or override these conditions and
set them differently for the arrangement, if allowed.
It is possible to automatically track the changes in the original Product
Conditions and update the defaulted values in an Arrangement. Conditions with
which the arrangement is created are called Arrangement Conditions. An
arrangement can be created with a back value date or a forward value date.
Currency is mandatory for Deposit arrangements.
When a financial arrangement is created, T24 will generate an Account record,
which maintains all activities in the deposit. This account is going to be used for
AA deposit from start to end. Before a deposit is placed with the bank, an
arrangement is created for the deposit amount expected from the customer. This
creates a bill for the expected amount. This bill will be in DUE status and
contingent entries will be raised for the expected amount.
After creating a new arrangement for deposit, there are occasions, when a
customer does not want to proceed with the deposit and wants to cancel the
same. After the arrangement has been cancelled, the arrangement account needs
to be closed. 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 will be created for the arrangement. It is also possible to redeem a

T3TAAD - R18 7
deposit either partially or in full before the maturity period.

T3TAAD - R18 7
AA Dependencies 8
 AA makes use of
 CUSTOMER
 ACCOUNT
 Core dependencies
 Delivery
 Accounting
 AA also uses other Static tables
AA uses the following T24 functionalities namely Customer records to refer a

counter party. We need accounts for the purpose of crediting the deposit
proceeds. AA is ACCOUNT based application. Whenever an arrangement is
opened, a T24 Account is opened automatically. This account holds deposit
balances. AA application is integrated with delivery. On authorisation of a
record, accounting entries are generated. AA application also makes use of other
static tables like Country, Holiday, Currency etc.

T3TAAD - R18 8
AA Dependencies – Interest related 9
BASIC.RATE.TEXT
Floating interest
BASIC.INTEREST
BASIC.INTEREST Table is used for applying floating interest in an

Arrangement. User can set margin to these rates. Index of the
BASIC.RATE.TEXT is set in the FLOATING.INDEX Field in product
condition. Interest rate defined in the relevant BASIC.INTEREST Table will be
defaulted into the arrangement using the product condition. You can optionally
add or deduct margin to the default rate.

T3TAAD - R18 9
AA Dependencies – Interest Related 10
Bid rate is used 10

for AA Deposits
Periodic interest
Generated daily
This table is used for LIBOR type rates, which vary depending on the length of
time and for Bid and Offer purposes.
For Loans and Deposit contracts that are linked to PERIODIC.AUTOMATIC
option, user will define a schedule for rate reviews. At the scheduled dates, the
system will refer to this table and automatically pick up the relevant rate and
apply that to the contract until the next review date. This table maybe
automatically updated or interfaced daily with an external feed such as Reuters,
or maintained manually by the user. PERIODIC.INTEREST keys are generated
daily by the System.

T3TAAD - R18 10
AA Dependencies - Currency related 11
11
COUNTRY REGION
HOLIDAY
CURRENCY.PARAM
CURRENCY CURRENCY.MARKET
Possible to indicate Countries and Regions in BUS.DAY.CENTRES Field in

Account Product Condition. Accordingly, while inputting an Arrangement,
holidays for those countries and regions will be checked and suitable
overrides generated
Currency is used in CURRENCY Field in AA.PRODUCT.DESIGNER Table
Holiday table will be used to check whether maturity or other scheduled activity
date is a working day or not at the time of inputting an arrangement. It is
possible to indicate countries and Regions in the multi value
BUSINESS.DAY.CENTRES Field in ACCOUNT Product condition, while
inputting a contract. Accordingly, while inputting an arrangement, holidays for
those countries and regions will be checked for all scheduled activities and
suitable overrides will be generated. Interest day basis will be defaulted to
transaction records as per the currency used.
CURRENCY.PARAM table contains common details for each Currency to
ensure that the same numeric code and no of decimals are used on different
currency files in a multi company environment.
It is possible to create different market rates for the same currency namely
separate rates for Notes or Travellers Cheques etc. Up to 99 markets can be
indicated in CURRENCY.MARKET table. Consolidation keys are formed
market wise. Markets beyond 9 will be consolidated with the market type of the
first digit for example 10 with 1.

T3TAAD - R18 11
AA Dependencies – Currency related 12
12
 Different Interest day basis for calculation of interest possible depending on

methods followed for calculating number of days in an interest period and days in a
year
Key Days/Denominator
A 360/360
A 360 / 360 A1 360/360
A2 360/360
 30 days in each month B 366/360
 360 days in an year C 366/366
A1 360 / 360 D 360/366
E 366/365
 Additional interest of February
F 360/365
 calculated on last day H 30/356
A2 360 / 360 F1 360/365
 Additional interest earned of February F2 360/365
S Special
 calculated on penultimate day
Different interest day basis for calculation of interest is possible depending on

methods followed for calculating number of days in an interest period and days
in a year. Input in this field determines the components for the interest
calculation.
The following values have been defined as Numerator and Denominator for
each type.
Type A is where each month is considered to have 30 days for the numerator
and the denominator will also be 360. Sub Divisions of A are A1 and A2. A1
360/360. For A1, additional interest for February is calculated on the last day of
February, under A2, it is calculated on the penultimate day of February. Under
Type B exact number of days will be considered in respect of the numerator
while the denominator will be 360. C is where the exact number of days will be
considered in respect of the numerator while the denominator will be 365 in a
non-leap year and 366 in a leap year. Method D is that each month is considered
to have 30 days for the numerator while the denominator will be 365 in a non-
leap year and 366 in a leap year. E method is where the exact number of days
will be considered in respect of the numerator while the denominator will be
365. F is the method where each month is considered to have 30 days for the
numerator while the denominator will be on a 365 basis. Subdivided into
methods F1 and F2. F1 and F2 are similar to A1 and A2 for calculation of
interest for additional days in February. Method H is where month is considered

T3TAAD - R18 12
to have 30 days for the numerator while the denominator will be 356. S is for Special
interest basis.

T3TAAD - R18 12
13
13
Application specific Parameters

T3TAAD - R18 13
AA - Tables used for building components 14
14
 Tables used for building re-usable components :
 AA.PROPERTY.CLASS
 AA.PROPERTY
 AA.PERIODIC.ATTRIBUTE.CLASS
 AA.PERIODIC.ATTRIBUTE
 AA.ACTIVITY.CLASS
 AA.ACTIVITY
 AA.PRD.DES.<PROPERTY.CLASS>
 AA.SOURCE.CALC.TYPE
 AA.PROPERTY.CLASS.ACTION
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 are released by Temenos and you can only amend their Description.
These components are reused by copying them as properties.

T3TAAD - R18 14
AA - Tables used for building components 15
15
Released by Temenos:

AA.PROPERTY.CLASS
AA.PERIODIC.ATTRIBUTE.CLASS
AA.PROPERTY.CLASS.ACTION
AA.ACTIVITY.CLASS
Tables set up during implementation:


AA.PROPERTY
AA.PRD.DES.<PROPERTY.CLASS>
AA.PERIODIC.ATTRIBUTE
AA.SOURCE.CALC.TYPE
These could be used across several products
Some of the tables used for building components are released by Temenos,
while some are set up during implementation. These building components, so set
up, can be used across several products.

T3TAAD - R18 15
AA.PROPERTY.CLASS 16
16
 Released by TEMENOS to define Actions and Attributes for any underlying

Property and Product condition
Type
Attributes controlled by TYPE Field Property
Examples : Class
CCY, OPT.CCY, DATED, MULTIPLE, MERGE,
FORWARD.DATED, TRACKING, NON.TRACKING ,
Product Line Balance
TRACKING.ONLY, ARRANGEMENT, TRIGGER
Prefix
ACCOUNTS, DEPOSITS,
INTERNET.SERVICES, LENDING,
PROXY.SERVICES, OTHER
Pre-fixes for Balance types controlled by
BALANCE.PREFIX Field
CUR, ACC, DUE, AGE, EXP, UND,

PAY, UNC, TOT
TYPE Field indicates the property class types. Details of various allowed types
are :
CCY – Product conditions for these products will vary by currency (e.g. interest
and principal conditions).
OPT.CCY - Indicates that properties may or may not have Currency component
in them.
DATED – Product conditions can vary by date. The property condition will
contain an effective date in the record key, if DATED is specified.
MULTIPLE – Allows more than one property of that class to be defined for a
single product.
MERGE – Allows Child condition not to override parent condition blindly.
FORWARD.DATED – Allows the user to introduce a new Activity charge
definition at the arrangement level.
ARRANGEMENT - Field values at the arrangement level will not be merged
with any of the previously amended arrangement values. Currently, only
BALANCE.MAINTENANCE property is defined with this type.
TRIGGER – Property appears in the arrangement after an Activity charge is
triggered and validated. Currently valid for CHARGE.OVERRIDE only.
Property Class to hold balances which are defined as allowed prefixes under

T3TAAD - R18 16
BALANCE.PREFIX for such balances.

T3TAAD - R18 16
AA.PROPERTY
17
 Property is a named type / instance of a Property Class

 Property is attached to Product Group from where it is derived in a Product
 Multiple properties of the same Property Class can be used in a Product, if so allowed
in the Property Class
 Property types:
Product only, Suspend, Suspend overdue, Residual, Variation, Forward dated,
Rebated unamortised, Credit, Trigger, Commission, Accrual by bills.
Or null
Slide 17
To create a Product, we require Properties. In AA we can create named types

(instances) of a Property Class which are known as PROPERTIES. We can
attach multiple properties to a Property Class in a Product Group, provided it is
allowed in the Property Class. PROPERTY.TYPE field: It can have a null value
or one of the following values:
Product only, Suspend, Suspend overdue, Residual, Variation, Forward dated,
Rebated unamortised, Credit, Trigger, Commission, Accrual by bills.

T3TAAD - R18 17
AA.PRD.DES.<Property Class> 18
18
 To be defined for every Property class, by associating Id of the respective

Property class
 AA.PRD.DES.TERM.AMOUNT, AA.PRD.DES.ACCOUNT
 Possible to create different Product Conditions for a Property Class

 Also possible to create different dated records for Product Condition
 Fields of a Product condition represent attributes of the associated Property

Class
Product Product
condition for Cancel condition for
Category
Term Amount Period Account
Posting
Amount Term Restrict Currency
What is the underlying application that is used to store all the information about
Product conditions?
Product Conditions belong to a Property Class and you can create different
Product Conditions for a Property Class.
For each Product Condition you can create different dated records.
For each property class a separate application is created with the name
AA.PRD.DES.<Property class name>.

T3TAAD - R18 18
AA.PRD.DES.<Property Class> 19
19
 Product conditions have to be Date specific if Property class is set so
 Can be currency specific if the corresponding Property Class allows it

 For product allowing multi currencies, product conditions for each of the currencies
must be defined
 Currency can be optional - e.g. Charge Product condition
 Currency and Effective Date form part of Product condition Id

 FIXED.RATE-USD-20100101; FIXED.INTEREST-GBP-20100101
 Possible to set conditions with future value date also
Attributes controlled by TYPE

Field Type Property
Class
CCY, OPT.CCY, DATED
Product condition can be currency specific and date specific. You may notice
that, in TERM.AMOUNT Product Condition, Currency USD is part of Id along
with date.
If Property class has TYPE set to CCY then Product condition will be currency
specific. For such Classes, Products that support multiple currencies will require
Product conditions for each currency. Product Conditions that are not currency
specific just have one condition, and currency will not be part of Id. Say, we
have a Product Condition called FIXED.INTEREST-USD, and the product
must support GBP as well, you need a Product Condition called
FIXED.INTEREST-GBP. When a new arrangement is created appropriate
conditions for currency of arrangement will be used.
Dated Product conditions can vary by date, and will contain an effective date in
record key.

T3TAAD - R18 19
Negotiation rules – Default Negotiable 20
20
 DEFAULT.NEGOTIABLE
Mandatory Field
Options: Yes and No
Defines whether all attributes (Fields) of the Property Class can be Negotiated or not
Attribute level negotiation rules will always override this setting
 DEFAULT.ATTR.OPTION
Optional Field
Option to reset arrangement conditions from the product during rollover, reset and change
product activities
 Option “RESETTING “ - conditions will be reset from Product
 Option “NON-RESETTING” – conditions will be maintained from Arrangement level
Now, we will go into the fields of Negotiation Rules tab in a product condition
and find out what they stand for.
DEFAULT.NEGOTIABLE Field - It is a Mandatory field. It has 2 Options: Yes
and No.
It defines whether all attributes (fields) of the Property Class can be set as
negotiable or not at the top level. This top level rule can be overruled by setting
the fields of specific attributes below.
DEFAULT.ATTR.OPTION is an optional field. Allowed Values are
RESETTING and NON-RESETTING.
RESETTING - During any Renewal Activities (for eg : change. product,
rollover or reset) the property conditions will be reset from the product.
NON-RESETTING – During Renewal Activities property conditions will be
maintained from the Arrangement level.

T3TAAD - R18 20
Negotiation rules –Negotiation rules 21
21
FOR ALL
DEFAULT.NEGOTIABLE ATTRIBUTES
NR.ATTRIBUTE NR.OPTIONS NR.TYPE NR.VALUE NR.MESSAGE
EB.
Negotiable COMPARISON.
Attribute of OVERRIDE
Non Negotiable TYPE Value for
Property class
Override comparison
(Fields of ERROR
Fix Value Equal, Like,
Arrangement)
Mandatory Range ….
Usual term : 5 years. Can be negotiated,

but only between 3 & 10 years
NR.ATTRIBUTE Field is a multi value field.

This specifies attributes of the Property Class, for which a negotiation rule is to
be defined in the associated Fields NR.OPTIONS through to NR.MESSAGE.
These attributes will be fields in the Arrangement.
Must be a valid attribute of the Property Class. In this example, where the
Product Condition is set for TERM.AMOUNT Property Class, it should be a
valid attribute name of TERM.AMOUNT Property Class.

T3TAAD - R18 21
AA.PROPERTY.CLASS.ACTION 22
22
 This application holds information on actions performed in each PROPERTY

CLASS
 The information covers:

 Actions for each PROPERTY CLASS
 Accounting entry generated or not for the action
 Product Line
AA.PROPERTY.CLASS.ACTION – This application holds information on

actions which can be performed with a PROPERTY CLASS.
It also indicates whether the action will generate an accounting entry and which
Product Line is affected.

T3TAAD - R18 22
What Did We Learn? 23
23
Conclusion  In this learning unit we have had a
 Basic overview of AA Deposits
 Core Dependencies
 Quick recap of property class type and

property type with product conditions

T3TAAD - R18 23
24 24
24
Basic Parameters in
Deposits

T3TAAD - R18 24
25
Objectives  In this learning unit let us discuss about the

Basic Parameters for Deposits Arrangements
 Customer Property Class
 Eligibility Property class
 Officer Property Class

T3TAAD - R18 25
AA Deposits Property Classes - Overview 26
26
Term Amount Interest Charge Payment Rules
Payment
Customer
Schedule
Account Closure
Deposits
Activity
Officers
Restriction
Tax Accounting
Activity Activity Activity Periodic

Presentation Mapping Charges charges
Any Deposits Product will have common features like Amount, Interest, Term,
Charges, Payment rules, Balances and Activities like Deposit payment, change
of conditions, etc.
In Deposits Product Line, these features are divided into various components,
and implemented through Property Classes.
The Key functional Property Classes include CUSTOMER, ACCOUNT,
ACCOUNTING, TERM.AMOUNT, PAYMENT.RULES,
PAYMENT.SCHEDULE, ACTIVITY.MAPPING and CLOSURE. In addition,
you have classes by which you can tell the system how the repayments need to
be apportioned, how to restrict activities over a period of time, how to charge on
specific Activities, etc.
You will be learning about the functional Property Classes of the Deposits
Product Line in this course.
The basics of AA framework and building blocks like Property Classes,
Properties, Product Conditions and how they can be used to create new Products
are covered in the “T24 AA – Core” Course, which is a pre-requisite to pursue
this Course.

T3TAAD - R18 26
CUSTOMER Property Class 27
27
Payment
Customer
Schedule
Account Closure
Deposits
Activity
Officers
Restriction
Tax Accounting

CUSTOMER is a mandatory Property Class of DEPOSITS Product Line. It is

used to specify the involved parties of an Arrangement and their respective
roles.

T3TAAD - R18 27
Customer - Property Class 28
28
 Customer Property class is mandatory
 Customer Property cannot be set as Tracking and it is Dated
Property
Type
Class
CUSTOMER
Attributes controlled by TYPE Field
DATED, NON.TRACKING
Balance
Prefix
Balance Prefix - Null
CUSTOMER Property Class is Dated and Non-Tracking type. Balance prefix is

Null.

T3TAAD - R18 28
Customer – Product Condition
29
 Product conditions can be set regarding Owners and Other Parties in Deposit
 Typically set as Negotiable at Arrangement level

 Multiple owners can be indicated
 First owner in Arrangement used for Accounting, Reporting
 Other owners can be added at new arrangement creation or later
 Possible to change the owner of the arrangement
Owner1
Owner
Owner 2
Other Party
Arrangement Other Party
Other Party
Slide 29
Customer Property Class is used by all Products to specify the involved parties
of an Arrangement and their respective roles.
Customer Property Class is primarily an Arrangement level class i.e. the values
will be input at an Arrangement level, and is typically configured at the Product
Level as fully negotiable. There can be more than one owner to an Arrangement.
Other parties can be added at the arrangement level and their roles can be
defined in virtual table AA.PARTY.ROLE. Other parties are valid T24
customers and cannot have any eligibility defined.
It is possible to change the owner of an arrangement using <PRODUCT.LINE>-
CHANGE-CUSTOMER activity class.

T3TAAD - R18 29
Customer – Product Condition
30
 Customer entered into New Arrangement Activity

 Must be a valid record in CUSTOMER application
 Eligibility would be validated for each customer in the owner
 Role specific Eligibility is possible
 AA.CUSTOMER.ROLE defines role of customer
 Indicates if customer is Beneficial owner
 Arrangement should have at least one Beneficial owner
 GL Customer and Limit customer field are mandatory
 for Beneficial owner (Functionality to be developed)
 Taxable customer can be indicated
 Maximum tax liability percentage can be indicated for taxable customer
 Default Tax percentage can be edited at arrangement
Slide 30
When an Arrangement is validated after inputting Customer and currency, the

customer specified will be automatically defaulted as the owner of the
Arrangement. Each arrangement can have one or more legal Owners. The first
owner is the one used by T24 for accounting, tax purposes and for limits.
AA.CUSTOMER.ROLE defines the role of the customer. The role of customer

can be indicated at the new arrangement activity level. Beneficial owner is
indicated at the AA.CUSTOMER.ROLE table.
If the customer is a beneficial owner, then he is also the GL customer and Limit
customer. Possible to indicate if the customer is taxable and if so what is the tax
liability percentage. The value of tax liability percentage, Limit Allocation
percentage and GL allocation Percentage can be edited at the arrangement level.
The customer can be indicated as Delivery customer and Relationship customer.
Limit related setup is not applicable for Deposits.
Based on Customer role if both are pricing customer, both customer should meet
the criteria for pricing product .
In R16, the functionality of Tax split based on Maximum Taxable Liability
Percentage is fully developed. The table ST.TAX.REPORT.DETAILS is updated
for the tax split related information. Tax type and Tax parameter table to support
tax split at customer level.

T3TAAD - R18 30
Customer Role at arrangement level
31
Slide 31
Here more than one owner is indicated for the first arrangement and the Tax
liability against each owner is defaulted based on AA.CUSTOMER.ROLE.
The tax liability percentage is editable.
AA ensures atleast one customer is Beneficial owner.

T3TAAD - R18 31
Eligibility Property Class
32
Payment
Customer
Schedule
Account Closure
Lending
Activity
Officers
Restriction
Overdue Accounting
Activity Activity Periodic

Eligibility
Mapping Charges Charges
Slide 32
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.

T3TAAD - R18 32
Eligibility - Property Class
33
Based on Eligibility conditions defined, eligibility of a customer for a product is

evaluated
 Product condition is Tracking and Date specific
Type Property Class

ELIGIBILITY
DATED, TRACKING, VARIATION, OPT.CCY

Balance
Prefix
Slide 33
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.
This property class is also variation specific property class and can be optionally
currency specific as well.

T3TAAD - R18 33
Eligibility
34
 Eligibility requirements for products can apply to:

Customer level products (e.g. Relationship Pricing or Internet Services)
Traditional “financial” products (e.g. loans, accounts, deposits)
 Eligibility checking enables:

Ability to specify eligibility criteria at the level of each product
Ability to evaluate if a customer is eligible for a particular product
 Frequency of eligibility requirement checking:

For some products, only once when the product is taken out
Rechecked during the life of the arrangement
 Customers who are no longer eligible (e.g. they are no longer resident) may need to
be moved to another product
34
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. When the primary customer of the arrangement is changed. Also
the eligibility may be rechecked during the life of the arrangement regularly or
any change in the customer information.
When customers are no longer eligible (e.g. they are no longer resident) for a
product may need to be moved to another product.

T3TAAD - R18 34
Creating rules for Eligibility
35
35
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.

T3TAAD - R18 35
36
36
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.

T3TAAD - R18 36
37
37
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.

T3TAAD - R18 37
Launch the T24 Toolbox by double clicking the icon.
38
38
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.

T3TAAD - R18 38
Linking Eligibility to Product condition
39
39
In this example, a rule is created for customers who are staff. The steps for
creating the rule is shown.

T3TAAD - R18 39
Establishing Eligibility
40
Eligibility requirements typically revolve around customer information :

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
Establishing eligibility
Filter the Product Catalogue to show only the products that the customer is eligible for
Check the customer’s eligibility during “New Arrangement” activity
Checking of eligibility requirement

When the product is taken out
When the primary customer changes
When there is a product change
Checked / Rechecked during the life of arrangement
40
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

T3TAAD - R18 40
Eligibility Property Class - product conditions
41
 Eligibility Review setup at the Product / Arrangement level

 Change in Customer static can trigger an Eligibility Review during the following
Close of Business
 Periodic evaluation
 Consequences of Eligibility Review Failure

 Change Product
 Ignore – this results in logging the failure on the arrangement
 Eligibility Product condition can be optionally currency specific
 Eligibility can be verified for Primary owner of the arrangement
 Possible to verify Role wise eligibility for other owners
Slide 41
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.
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. Close option is available only for
Relationship pricing and not for other product lines.
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. Any change in
customer static can trigger the eligibility review during the following close of business.
The eligibility review failure can result in:
a. Change Product wherein system picks out the Default product given in product condition and moves to
that product.
b. Ignore - this results in logging the failure on the arrangement. Available for view in arrangement
Overview.
CLOSE option is applicable only for Relationship pricing products and would not be allowed for any other
product line.
Eligibility property class defines conditions for different currencies or a common condition for all
currencies i.e. Currency is an optional component in the product condition ID.
Eligibility can be defined role specific rules as well as a default rules which apply for all customers
regardless of the role.

T3TAAD - R18 41
Eligibility product conditions
42
Default product - for failed eligibility
 Eligibility product condition not included in the product designer
 DEFAULT.PRODUCT set to YES
 Indicated as ELIGIBILE.DEFAULT.PRD in Eligibility product condition of other

products
42
When defining a default product(for failed eligibility), eligibility condition is

not included in the product designer and DEFAULT.PRODUCT in product
designer is set to Yes.
For subsequently created products, eligibility product condition contains this
product as ELIGIBILE.DEFAULT.PRD. This would be the default product to
which the arrangement has to be moved on rule failure during cob.

T3TAAD - R18 42
Workshop – ELIGIBILITY Product Condition
43
 Use Admin Menu > Product Builder > Product Conditions > ELIGIBILITY
Create Eligibility product conditions for variations Staff and Local Resident in
EB.LOOKUP
Ensure it matches in EB.RULE.GATEWAY to the rule referred earlier.
• Customer is staff
• Customer is foreigner
Arrangement should not be created on failure of eligibility.

On a static review, upon eligibility failure, system should change to default product.
The default product is currently chosen as Negotiable deposit
Slide 43
Create Eligibility product conditions for variations created earlier in

EB.LOOKUP
Ensure it matches in EB.RULE.GATEWAY to the rule referred earlier.
• Customer is staff
• Customer is foreigner
Arrangement should not be created on failure of eligibility.

On a static review, upon eligibility failure, system should change to
default product.
The default product is currently chosen as Negotiable loan

T3TAAD - R18 43
Workshop – ELIGIBILITY Product Condition 44
44
Variation created for Local resident and Staff customer.

T3TAAD - R18 44
Workshop Solution
45
Slide 45
Eligibility condition setup for Local resident and staff.

T3TAAD - R18 45
Officers Property Class 46
46
Payment
Customer
Schedule
Account Closure
Deposits
Activity
Officers
Restriction
Tax Accounting

OFFICERS is an optional Property Class of DEPOSITS Product Line. The

ACCOUNT.OFFICER is an important mandatory field in an Account and the
value input will be updated in the Account automatically created for the
Arrangement.

T3TAAD - R18 46
Officers - Property Class 47
47
 Property for Officers can be set as Tracking
 Update Action possible. Values in fields can be updated at Arrangement level

 Will not generate Accounting entry
Property
Attributes
Types Class
DATED, TRACKING OFFICERS
OFFICER Property Class is Dated and Tracking type.

T3TAAD - R18 47
Officers – Product Condition 48
48
 Primary Officer - Main officer responsible for the Product or Arrangement
 Other Officers - Other officers have specified role
Both of above must be a valid Officer in DEPT.ACCT.OFFICER file
 Roles for Other Officers

 A Role for each officer can be defined
 Must be a valid role defined in AA.OFFICER.ROLE Virtual Table
 Notes for Other Officers
 Default value is Account Officer defined in CUSTOMER record
The PRIMARY.OFFICER input is the main Officer responsible for the

Arrangement.
The input in an Arrangement will update the ACCOUNT.OFFICER Field of the
AA Account.
If there is no input in an Arrangement, the value of ACCOUNT.OFFICER in AA
Account value will be defaulted from the Customer record. Thus, the
OFFICERS is only an optional Property Class of DEPOSITS. The Account
Officer value of Accounts is useful to consolidate balances and report them
Department/Account Officer-wise.
Additional officers who can assist with a Product/Arrangement or those will be
responsible in the absence of Primary Officer can be specified in the multi-
valued OTHER.OFFICER Field. The value input here will be defaulted in the
OTHER.OFFICER Field of AA Account.
The role of Other officers can be input in the field ROLE.
The Roles of Other Officers are picked up from the virtual table
AA.OFFICER.ROLE, which can be maintained using the EB.LOOKUP
application.

T3TAAD - R18 48
Workshop –OFFICERS settings 49
49
 Use Admin Menu > Product Builder > Product Conditions > OFFICERS
 Create a new Product Condition
 Set the following rules :

For Other Officer Use codes “3 “ and “27” and role as “Application” and
“Approval” respectively
Set DEFAULT.NEGOTIABLE to Yes
Create an Officers Product condition.

T3TAAD - R18 49
Workshop - Solution 50
50
In this workshop, we will see how to create an Officers Product condition:

Set the following rules :
For Other Officer Use codes “3 “ and “27” and role as “Application” and
“Approval” respectively.
Set DEFAULT.NEGOTIABLE to Yes.

T3TAAD - R18 50
Quiz – Choose the correct Answer 51
51
Quiz
1. The Primary Customer of an Arrangement can be changed only
with a Joint Owner
a) True
b) False
2. Eligibility is checked only for the first customer
a) True
b) False

T3TAAD - R18 51
52
Conclusion  We have now learn about
 Customer Property Class
 Eligibility Property class
 Officer Property Class

T3TAAD - R18 52
53 53
53
Deposit Amount

T3TAAD - R18 53
54

Parameters for Deposit Amount
 Term Amount Property Class
 Account Property Class

T3TAAD - R18 54
Term Amount Property Class 55
55
Payment
Customer
Schedule
Account Closure
Deposits
Activity
Officers
Restriction
Tax Accounting

TERM.AMOUNT is a mandatory Property Class of DEPOSITS Product Line.

This Property is used to input values of Term (Period) of the Arrangement and
its committed Amount.

T3TAAD - R18 55
Term Amount - Property Class 56
56
Property Class
 Represents both commitment amount and the Term
TERM.AMOUNT
 Term amount is currency specific Type

Balance
Attributes Prefix
CCY, DATED,
NON.TRACKING
Pre-fixes for Balance types controlled
by BALANCE.PREFIX Field
TOT
The Term Amount property class represents both the amount committed within
the Arrangement and the term of that Commitment.
This property class controls the commitment made between the bank and the
customer.
Term Amount is Currency specific.
For a Product Condition linked to Term Amount in a Deposits Product, you must
create a Condition for each allowed Currency of the Product.

T3TAAD - R18 56
Term Amount – Product Condition 57
57
 Committed Amount
 Amount of deposit for the term
 Term
 Period of time by which the amount must be repaid to Customer
 Maturity Date
Date on which term ends
Calculated from Agreement Date and Repayment Term
 While booking a new arrangement, when TERM and maturity date are present and
TERM is changed then maturity date will be re-calculated
In an Arrangement, the AMOUNT Field is used to enter the total amount called
commitment amount which will be deposited for the term. The amount can be
restricted in the Product Condition through appropriate negotiation rules (e.g.
>5000 and < 25000).
The TERM field determines the period of time by which the amount must be
repaid by the Bank. It is common to specify a default value for this in the
Product Condition, for example 2Y for a term deposit. The term can be entered
as a number of Days (D), Weeks (W), Months (M), or Years (Y).
The MATURITY.DATE at the Arrangement level is calculated. This is based
upon the Arrangement Effective Date and Term. User can also manually enter
the MATURITY.DATE instead of defining the TERM of the arrangement. At the
arrangement level, if maturity date is changed then TERM will be calculated in
DAYS format. If TERM and maturity date are present and TERM is changed
then an internal maturity date will be calculated. If this date is not equal to the
existing maturity date then TERM will be recalculated and updated in DAYS
format. Hence, when TERM is changed and maturity date has to be recalculated
then existing maturity date must be cleared.

T3TAAD - R18 57
Maturity Date & Term of Contract 58
58
 When Maturity Date is calculated based on Term, it is optional to verify

the holiday convention
 MAT.DATE.CONVENTION can be set to YES – If maturity date falls on a

holiday date convention specified in Account property class is followed -
maturity date is adjusted
 When not set, override is raised when maturity date falls on holiday –
when accepted, arrangement is created with maturity date on the holiday
 Override is generated when maturity date is input manually and if it falls

on a holiday
 When the adjusted maturity date is beyond the tolerance indicated in

TERM.TOL.DAYS, term is recalculated – Else the original term is retained
When Maturity Date is calculated based on Term, it is optional to verify the holiday convention
Till R16, when the maturity date falls on a holiday, an override is raised. User can either accept
the override and go ahead with the arrangement or update the maturity date accordingly.
From R17, when the maturity date falls on a holiday, date convention specified in Account
property class may be followed. Two new fields are introduced namely Maturity Date
Convention MAT.DATE.CONVENTION and term tolerance TERM.TOL.DAYS for the same.
When MAT.DATE.CONVENTION is set as “YES” , if calculated maturity date falls on
holiday, is replaced by moving the maturity date according to the set up in
DATE.CONVENTION field in ACCOUNT product condition. It can be moved Forward,
Backward or Forward Same Month. Calendar option will not adjust the maturity date. Interest
will be calculated for the total number of the days of the contract as per regular functionality.
Note that if the holiday is declared after the arrangement creation, it would not be adjusted
automatically.
In spite of setting up Maturity date convention as YES, if the user wants the maturity date to be
same on the holiday - maturity date can be input manually on the maturity date field. This results
in an override, when accepted the arrangement can completed.
When the adjustment of maturity date is beyond certain number of days, its ideal to update the
TERM accordingly. TERM.TOL.DAYS indicates the number of days adjusted beyond which
the TERM would be recalculated.
When the Term based rates is used for the Deposit in the form of periodic interest for the term
If there is shift in maturity date within the tolerance days, term is not updated and original Term
is used to arrive at the periodic rates.
If the shift in maturity date is beyond the tolerance days, term is updated (re-calculated from the
maturity date). This adjusted term will in turn be used to arrive at the periodic rates.

T3TAAD - R18 58
59
 Cancel Period
If committed deposit amount is not paid by the customer, system triggers cancellation
of deposit after this period
 Notification of Pending Cancellation

 Pre-advice by a specified number of days in advance
 Amount on Maturity
 On Maturity of arrangement, to keep remaining amount as Due or Outstanding
CANCEL.PERIOD –The Period after which if full committed deposit amount is

not paid by the customer, system triggers cancellation of deposits. The number
of days is calculated from arrangement start date, after which, if full payment is
not made toward the deposit arrangement, system would schedule the activity
DEPOSITS-CANCEL-ARRANGEMENT which would trigger the cancellation.
If partial payment is made then it would be reverted and credited to UNC.
It is possible to generate a pre advice by specified number of days in advance to
indicate pending cancellation of the arrangement, if the contract is not fully
funded.
This is effected through ACTIVITY.MESSAGING property which has
associated multi-value fields PRE.NOTICE.ACTIVITY and
PRE.NOTICE.DAYS.
PRE.NOTICE.ACTIVITY Field controls the activity for generating the advice
for an Activity, say, DEPOSITS-CANCEL-ARRANGEMENT. The field
PRE.NOTICE.DAYS controls the time in advance when the notification will be
produced. To know more about Activity Messaging Property Class, please refer
to AA Technical course.
ON.MATURITY Field determines whether on Maturity Date of the
arrangement, the remaining amount in outstanding balance to be kept as Due or
(Null) Outstanding.

T3TAAD - R18 59
60
 Pre-closure of Deposit within a time frame - Cooling Off Period

Without any charge to Customer
No Interest paid to Customer
 Cooling Period attribute

Defines the period within which a customer can withdraw or pre-close the
arrangement
 Pre-closure of Deposit after the cooling off period

 Charge can be collected through periodic attributes and Activity Restriction
Arrangement is pre-closed using the activity DEPOSIT-REDEEM-

ARRANGEMENT. If this is done within the Cooling period specified no
interest will be calculated for the principal amount. Charges that are levied will
also be returned back to the customer.
Cooling period field will indicate the period within which the customer can
withdraw or pre-close the arrangement. The term can be entered as: Days
(calendar1) (nnnnD), Weeks (nnnnW), Months (nnnnM), Years (nnY). This
value is also stored in the file AA.ACCOUNT.DETAILS file in the field
COOLING.DATE in a period format.
How does the Bank collect charges for pre-closure of Deposits that is triggered
after the cooling off period?
Any charge that needs to be collected for pre-closure after the cooling off period
can be controlled using AA.PERIODIC.ATTRIBUTE along with Activity
Restriction activity. Under periodic attributes, an option in RULE.START called
COOLING-OFF will control the collection of charges. This option will decide
the start date from which periodic restriction is to be applied. If COOLING-
OFF is opted, then periodic restriction will start from the date of Cooling date as
specified in AA.ACCOUNT.DETAILS. You will see more of this when we talk
of the Periodic attributes.

T3TAAD - R18 60
61
 Interest payment made during the Cooling Off Period

Schedules configured and processed for Interest payment
No reversal of Pay balances during redemption calculation
 Override to notify the user if activity scheduled during cooling period

At arrangement level
Also at funds transfer stage
 Cooling Period for rollovers

Same principle as for regular deposits
Base date Type to be set as Agreement in Account property
There may be cases where schedules can be configured and get processed before
the cooling period has expired. Any interest or principal amounts that have
already been paid from the pay balances to the customer within this cooling
period will not be taken into consideration in the redemption calculation and the
pay balances will not be reversed. Whenever a schedule is configured to do an
activity before the cooling off period a suitable OVERRIDE is produced at the
arrangement level and also at the funds transfer stage to notify the user.
The same principle of cooling off is applicable for rollovers as well. A customer
is eligible to withdraw the money as on rollover date without any further interest
amount being paid back to the customer. For this to happen, it is essential that
the field BASE.DATE.TYPE is set to AGREEEMENT in the ACCOUNT
Property class.

T3TAAD - R18 61
Term Amount – Call Deposit 62
62
 Some deposits may be considered as call products
Term and Maturity Date attributes are optional at arrangement capture level
and in the related product condition
Product where Term and Maturity date are not specified in Term amount
property is a call product
 For a Call product, Change Product property should not be configured
If Change Product Property is configured with a value specified in either

Change Period or Change Date, it is considered Fixed Term
Some Deposits may be considered as Call products. TERM and

MATURITY.DATE fields are optional while configuring the Term Amount
Product Condition and at the arrangement capture stage. If the Property
CHANGE.PRODUCT is not configured in the product and the TERM and
MATURITY.DATE Fields are not specified then this is considered to be a call
type arrangement. The CRF reporting will report the contract as such.
If CHANGE.PRODUCT Property is configured in the product and a value is
specified in either CHANGE.PERIOD or CHANGE.DATE Field, then this is
considered to be a fixed term deposit with either of these values being taken as
the maturity date which will renew either automatically or manually on this
date. Thus it becomes a Fixed Term rollover product.
For a rollover, we can specify the final maturity date through the activity
DEPOSIT-CHANGE.TERM-COMMITMENT. Once this activity is run , TERM
and MATURITY.DATE can be entered, the contract will then finally mature on
this date.

T3TAAD - R18 62
Term Amount – Call Deposit CRF Reporting 63
63
 CONSOLIDATE.COND will refer to REPORT.END.DATE in AA.ACCOUNT.DETAILS

instead of MATURITY.DATE for contract maturity reports
 CRF reporting handles contracts with:

Specified maturity dates
No maturity date (Call)
Specified renewal dates
 REPORT.END.DATE Field in AA.ACCOUNT.DETAILS is updated thus:

 The next renewal date if it precedes the maturity date or
 The maturity date if there is no renewal scheduled before the maturity date
 NULL if it is a call contract and there is no renewal scheduled
As TERM and MATURTY.DATE fields are optional, CRF reporting needs to

handle contracts with a) specified maturity dates, b) no maturity date (call), c)
contracts with specified renewal dates. For CRF reporting ,
CONSOLIDATE.COND will refer to REPORT.END.DATE in
AA.ACCOUNT.DETAILS instead of MATURITY.DATE for contract maturity
reports.
A field REPORT.END.DATE is available in AA.ACCOUNT.DETAILS and is
updated in the following order:
1) If the next renewal date precedes the MATURITY.DATE, due to input of a
value in either of the fields CHANGE.DATE or CHANGE.PERIOD in
CHANGE.PRODUCT property, then use the preceding renewal date
2) The MATURITY.DATE if no renewal is scheduled before the maturity date
3) NULL if it is a call contract and there is no renewal scheduled
For example, when the call contract (arrangement) is created with change
product scheduled on 01/06/2011, then REPORT.END.DATE field will be
updated as 01/06/2011. On crossing the renewal date, if no further renewal is
scheduled, REPORT.END.DATE field will be updated as null
For the system to calculate future cash flows for IFRS a final maturity date is
needed. With the TERM and MATURITY.DATE fields being optional, it is not
possible. So validation and an error message has been introduced notifying the

T3TAAD - R18 63
user in such an instance.

T3TAAD - R18 63
Term Amount – Other features 64
64
Automatic funding of deposit is possible

 Can be run directly from the Arrangement
Transfer funds from a specified account to a Deposits Arrangement
APPLYPAYMENT activity for Partial repayment acceptable, if set so
Subject to Expected Balance and Activity Restriction, if any

Payments received in excess of Expected Balance held in UNC
Possible to generate swift messages MT320, MT330, MT350, MT935 during Deposit
confirmation message, Rate change and payment advice
Deposits can be automatically funded when an Arrangement is created. It can be

done directly from the Arrangement similar to other Activities like increase
Term Amount.
Payments to Deposits will be received through external channels like Funds
Transfer, Teller and credited to the arrangement as per allocation rules set.
Partial payment towards a Deposit is acceptable, if set so for the product.
System validates the payment received against the expected balance, the current
outstanding amount and any applicable Activity Restriction.
When a deposit is placed with the bank, an arrangement is created for the
deposit amount expected from the customer through a new arrangement activity
DEPOSITS-NEW-ARRANGEMENT. This creates a bill for the expected
amount, which will be in DUE status under ACCOUNT property. Contingent
entries will be raised for the expected amount in balances of TERM.AMOUNT
and ACCOUNT properties as follows:
On receiving the payment towards Deposit EXPACCOUNT becomes zero and
TOTCOMMITMENT equals the term amount. When APPLYPAYMENT
activity for Partial repayment occurs EXPACCOUNT will be the difference
between Term amount less the payment received and TOTCOMMITMENT will
equal the payment received.
When payment is received in excess of the issued bill amounts, excess amount is

T3TAAD - R18 64
held in UNC balance.
Swift messages can be generated for Fixed MT320 Fixed Loan / Deposit Confirmation,
MT330 Call Loan / Deposit Confirmation, MT350 Advice of Loan / Deposit Interest
Payment, MT935 Rate Change Advice. Deal date of the swift message is populated
using contract date field of AA.ACCOUNT.DETAILS (TRADE.DATE of new
arrangement activity). It Stores the rollover dates as set of multi-value fields of Contract
date.

T3TAAD - R18 64
Workshop – TERM DEPOSIT settings 65
65
 Use Admin Menu > Product Builder > Product Conditions > TERM.AMOUNT
Set default amount to 40,000 which can be changed to a minimum of 20,000, but not
less and to a maximum of 200,000 and above with overrides

Default term is 3 years which is negotiable between 1 and 5 years
Term below 1 year can be allowed but beyond 5 years not to be allowed
If the total deposit amount is not paid by customer within 5 days of opening, the
deposit arrangement should be cancelled
 Set DEFAULT.NEGOTIABLE to Yes

 Commit the record
Create a Term Amount Product condition for a term deposit product with
maturity.

T3TAAD - R18 65
Workshop – Solution 66
66
In this workshop, we will see how to create a Term Amount Product condition
for a term deposit product:
Set default amount to 40,000
Default term is 3 years
If the total deposit amount is not paid by customer within 5 days of
opening, the deposit arrangement should be cancelled
Amount can be negotiated to a minimum of 20,000, but not less and to
a maximum of 200,000 and above with overrides
Term is negotiable between 1 and 5 years, below 1 year can be allowed
but beyond 5 years not to be allowed
Set DEFAULT.NEGOTIABLE to Yes

T3TAAD - R18 66
Workshop – CALL DEPOSIT settings 67
67
 Use Admin Menu > Product Builder > Product Conditions > TERM.AMOUNT

Amount and Term attributes to be left blank

Term ,Maturity Date and Cancel Period attributes to be made Negotiable
Amount can be permitted up to 500,000, not above that
Customer can withdraw / pre-close the arrangement within 5 days of opening the
deposit
 Set DEFAULT.NEGOTIABLE to No
Create a Term Amount Product condition for a Call deposit.

T3TAAD - R18 67
68
In this workshop, we will see how to create a Term Amount Product condition
for a Call deposit product:
Amount and Term attributes to be left blank.
Customer can withdraw / pre-close the arrangement within 5 days of
opening the deposit.
Term and Maturity Date attributes to be made Negotiable.
Amount can be permitted up to 500,000, not above that.
Cancel Period attribute to be made Negotiable.
Set DEFAULT.NEGOTIABLE to No.

T3TAAD - R18 68
Account Property Class 69
69
Payment
Customer
Schedule
Account Closure
Deposits
Activity
Officers
Restriction
Tax Accounting

ACCOUNT is also a mandatory Property Class of DEPOSITS Product Line.

When an Arrangement is created for a Deposits Product, T24 will automatically
create an Account, which will be used to maintain the balances of the
Arrangement.

T3TAAD - R18 69
Account - Property Class 70
70
 ACCOUNT Property Class is Dated
 CUR, DUE, AGE, UNC, UND, EXP and PAY are the allowed Balance Prefix
Property
Types Class
Attributes
ACCOUNT
DATED
Balance
Pre-fixes for Balance types controlled by Prefix
DEPOSITS – CUR, DUE, AGE, UNC, UND, EXP, PAY
ACCOUNT Property Class is Dated. This property class holds principal

balances of an arrangement.

T3TAAD - R18 70
Account – Product Condition 71
71
Category
Accounts use Customer type of Account Category codes - Range 1000 to 9999
Must be Non-contingent, avoid ranges meant for Nostro, Vostro
Usually set as Non-Negotiable
Account Title, Short Title and Mnemonic

Account Title for descriptive details
Short title used for enrichment
Mnemonic is used as alternate Id
When you open a Customer Account in T24, three fields are mandatory which
are Customer, Category and Currency. Of these, the Customer and Currency will
be supplied by the mandatory values input first for a Deposit Arrangement. So
only Category needs to be specified for an Arrangement once it is validated with
the Customer and Currency values.
A T24 Customer Account can be opened only in the Category range of 1000-
9999.
Category, which is used to distinguish T24 Products, is an important field of
Account, and financial reporting is usually based on T24 Product Categories.
Some of the Account Categories are reserved for Nostro, Vostro Accounts.
Normally, Category will be set as a non-negotiable attribute in an ACCOUNT.
Product Condition, with a default value i.e. Category value will be defaulted in
the Arrangement and User cannot modify it. This will help to group AA Deposits
Products in a meaningful manner for financial reporting. Of course, though any
Category in the range 1000 to 9999 can be specified here, care should be taken
to avoid Categories, which are reserved for other types of Accounts like Vostro,
Nostro, etc.
Finally, you can see that all other attributes have been set to be negotiable i.e.
User can input own values for other attributes of Account in an Arrangement.

T3TAAD - R18 71
Account – Posting Restrictions Slide 72
72
 Possible to set up multiple Posting Restrictions for a specific start date and end date
 Blocking Code can be indicated through virtual table PR.REASON and Blocking reason
as free text
 Unblocking Code is indicated through virtual table PR.REMOVAL.REASON with

Unblocking reason as free text
 <PRODUCTLINE>-START.RESTRICTION-ACCOUNT and <PRODUCTLINE>-

END.RESTRICTION-ACCOUNT - Pre-notice is configurable
From R17, it is possible to setup multiple posting restrictions in START.DATE,

BLOCKING.CODE, BLOCKING.REASON, EXPIRY.DATE,
UNBLOCKING.CODE, UNBLOCKING.REASON.
Multiple restrictions can be attached to restrict debits, credits or both (as per
existing functionality).
Blocking Code can be indicated through virtual table PR.REASON and
Blocking reason as free text. Unblocking Code is indicated through virtual table
PR.REMOVAL.REASON with Unblocking reason as free text.
Posting restriction effected immediately when Start date is blank and Posting
Restriction can be scheduled - effective from a future date indicating the date in
Start date (applies from that SOD) and cannot be backdated. Note, Start date
cannot be updated for an active restriction.
Expiry date can be set as current date or future date – applies from SOD.
For a given start date without Expiry date the posting restriction is for life of
arrangement.
Blocking and unblocking codes can be indicated or free text can be used to
indicate the reasons.
DEPOSITS-START.RESTRICTION-ACCOUNT activity and DEPOSITS-
END.RESTRICTION-ACCOUNT activity are for initiating and finishing
posting restriction and can be scheduled. Pre-notice is configurable for these
activities.
Note that these fields can be opened for user update where the user can

T3TAAD - R18 72
themselves post a restriction when they want the account to be blocked (Customer
travelling out of station and wants to safe guard from fraudulent transactions in his
deposit).

T3TAAD - R18 72
73
Currency
Currency of Arrangement
Defaulted from Currency of New Arrangement Activity
Cannot be changed after authorisation of arrangement
Base Date Type

Option to determine calculation start date
 Agreement - will start calculations from date of arrangement

 Start - Will start from First or initial deposit date
Securities valuation enquiry

Portfolio number at arrangement level enables Securities valuation enquiry
Stores the identification number of SEC.ACC.MASTER
CURRENCY Field identifies the currency of the account and all entries posted
to this account are in this currency. Once an arrangement is authorised, currency
cannot be changed.
BASE.DATE.TYPE Field is a no change field at the arrangement level. It
indicates if Anniversary field should be from agreement date or from first or
initial deposit date. Option AGREEMENT would commence calculation from
date of arrangement. Option START would commence calculation from First or
initial deposit date for deposits, E.g. 10T can be deposited in lots like 2T, 5T, 3T
etc. and START refers to initial deposit of 2T. A point to note is that cooling off
period functionality of Term Amount property is applicable for rollover only
when this field is set to AGREEMENT.
PORTFOLIO.ID Field is available in product condition (not in MB version)
wherein, it should be left blank and negotiable. This field can be used at
arrangement level to input the portfolio number of the Customer. This will link
the customer’s deposit arrangements to his Securities portfolio, thus reflecting in
the Securities valuation enquiry information like nominal amount, interest rate,
maturity date and accrued interest rate to date. A drill down to the underlying
contract is also available. Please note that an arrangement will become active in
a portfolio only after a settlement has been done. Further, any changes made in
the deposit like interest rate change, redemption, partial funding within cancel
period, partial withdrawal of deposit, increase of term amount, term etc. will

T3TAAD - R18 73
reflect in the portfolio indicating movement of funds.

T3TAAD - R18 73
74
 Bus Day Centres

 Holiday table of country / region to determine non-working days
 Date Convention
 Schedule for non-working days
 Forward; Backward; Forward Same Month; Calendar
 Date Adjustment
Value - All schedule events calculated on VALUE Date of Arrangement
Period - Every schedule event calculated on previous schedule date
Not applicable when Date Convention is Calendar
BUS.DAY.CENTRES : By default, T24 will check the holiday schedule for

country of an arrangement currency to determine non-working days. You can
add additional countries (Business Day Centres) whose calendars must be
checked with regard to holiday.
DATE.CONVENTION : Date Convention and Date Adjustment settings indicate
the action taken if the derived date is a non-working day. Options are:
Backward – the payment date will move backward to the previous working day.
Forward – the payment date will move forward to the next working day.
Forward Same Month –payment date will move forward to the next working day
provided it is within the same month. Otherwise, it will move backward to
previous working day.
Calendar –payment date will not move regardless of working day.
DATE.ADJUSTMENT Field is used for all date conventions except for
Calendar. Date Adjustment is used to specify whether new date will represent an
adjustment of the ‘Value’ date of the entries (Actual payment date does not get
adjusted) or an adjust of the ‘Period’ (Actual payment date gets cycled).

T3TAAD - R18 74
Account – Other features 75
75
 Account is required for all financial Arrangements

 Holds the Principal balance of the Arrangement
 Allows changes to the following Account attributes:

 Account Title, Short Title, Posting Restriction, Mnemonic
 Dormancy setup
 Inactive months - Number of months without customer activity before an

Arrangement Account is declared as Inactive
 As an alternate, Dormancy Property class can be setup to update the dormancy
Account is required for all financial Arrangements. It holds the Principal balance
of the Arrangement.
It is not recommended to update the Category of an account. If you want to
change the Account to a different Category, it can be done through the
CHANGE.PRODUCT Activity. User can amend the account title, short title,
posting restriction and account mnemonic. The Account number which has
been automatically created cannot be changed.
Inactive months - Number of months without customer activity before an

Arrangement Account is declared as Inactive.
As an alternate, Dormancy Property class can be setup to update the dormancy.
To learn more about Dormancy go through the Dormancy Property Class
ELearning Material.

T3TAAD - R18 75
Workshop – ACCOUNT settings 76
76
 Use Admin Menu > Product Builder > Product Conditions > ACCOUNT
 Set the following rules:
 Use Category Code 6608
Set Base Date Type to AGREEMENT
Fill in ACCOUNT.TYPE and ACCOUNT.NAME Fields with title names you desire
 CATEGORY must be NON-NEGOTIABLE
 All other attributes, by default are Negotiable
Create a new Account Product Condition

T3TAAD - R18 76
Workshop - Solution 77
77
In this workshop, we will see how to create an Account Product

condition.
Set the following rules:
 Use Category Code 6608
 Set Base Date Type to AGREEMENT
 Fill in ACCOUNT.TITLE and SHORT.TITLE Fields with title
names you desire
 CATEGORY must be NON-NEGOTIABLE
 All other attributes, by default are Negotiable

T3TAAD - R18 77
78
Quiz
1. Term amount property class can be used to create call and notice
deposits
a) True
b) False
2. AA Account can use any Account Category Code
a) True
b) False

T3TAAD - R18 78
79
 Term Amount Property Class
 Account Property Class

T3TAAD - R18 79
80 80
80
Interest and Tax Setup

T3TAAD - R18 80
81

Parameters for Interest and Tax setup
 Interest property Class
 Tax Property Class

T3TAAD - R18 81
Interest Property Class 82
82
Payment
Customer
Schedule
Account Closure
Deposits
Activity
Officers
Restriction
Tax Accounting

INTEREST is an optional Property Class of DEPOSITS Product Line. This

Property is used to define the attributes for interest calculation.

T3TAAD - R18 82
Interest – Property Class 83
83
 Multiple Interest properties can be defined
 Interest property is tracking
Property
Attributes Class
Types INTEREST
DATED, CCY, MULTIPLE,
TRACKING,
FORWARD.DATED
Balance
Prefix
ACC, PAY, DEF , DUE
Interest Property Class is used for all interest definition and processing in AA. A
T24 product defined and processed in AA can have multiple interest properties
defined. The number of interest properties is determined by the users defining
the products. During an activity, if permitted, user can amend or delete any of
the future conditions.
From R15, Forward conditions can be effective dated based on Anniversary,
Start date or Arrangement date at the Product designer level – If negotiable the
values can be amended at arrangement level. You may recollect that this
discussed in AA Core courseware already.

T3TAAD - R18 83
Interest – Product Condition 84
84
 Interest Types
Fixed interest
 Interest Rate to be specified
Floating interest
 Id of BASIC.RATE.TEXT table to be specified
Periodic interest
 Id of PERIODIC.INTEREST table to be input
 Interest rate is defaulted for the TERM of the arrangement
 Interest rate for TERM falling between periods defined in the table can be interpolated
If user inputs a rate, system will not default rates from BASIC.INTEREST Table or
PERIODIC.INTEREST Table
 Periodic Interest can be reset at predefined frequency
 Possible to also give a custom rate calculation for Interest
Fixed interest, Floating Interest and Periodic Interests are allowed. Margins can
be set. You have to input interest rate for Fixed interest type. For Floating
Interest type, rate will be defaulted from related BASIC.INTEREST Table for
the Arrangement Currency.
For Periodic Interest type, rate applicable to the Arrangement Period will be
defaulted from the PERIODIC.INTEREST Table. If the Term of the
arrangement is not matching with the periods defined in the
PERIODIC.INTEREST Table, System will calculate interest by Interpolating
the rates available for different periods in the Periodic Interest Table. This is the
default option. Other available options are NEXT, PREVIOUS and CLOSEST.
You can set frequency for resetting the interest rates under
PERIODIC.INTEREST type. When the next periodic reset date (i.e. the interest
reset activity) is computed and if it happens to be a holiday, Business day
definition fields in Account property would be considered and the date would be
moved to a working day just like a scheduled repayment.
A “Custom Rate” can be used for Interest calculation from R18. An API to be
attached for deriving the Rate. In model bank we have a currency weighted
Average Rate calculation API to calculate the custom rate.

T3TAAD - R18 84
85
 Tiered interest Rates
 Interest rates can be defined as a single tier, or multiple tiers
 With multiple tiers, rate varies according to balance amount

 Level – rate is level across the whole balance
 Banded – rate varies between bands
 Each tier can have a different rate type
 Each tier can have different margins
 Minimum and Maximum rates for each tier can be defined
T24 allows for the definition of tiers of interest rates. Each tier is specified by
defining the amount upto which the interest rate applies. Additionally, each tier
can be of a different interest rate type (i.e. fixed, floating, or periodic). There
are three type of tiers. RATE.TIER.TYPE Field has 3 options – Single, Level
and Banded.
Single Rate - When a single rate tier type is specified a single nominal interest
rate will apply for the entire balance amount.
Level Rate - This will calculate interest at different rates depending on the
balance amount.
Banded Rate - Banded tier interest will typically result in a “blended” interest
rate. This is similar to Level tiers, but allows for the interest rate of each tier to
be applied to the portion of the balance that falls within the tier. Compounding
not permitted for this.
Margins, Minimum rate and Maximum Rate for each tier can be specified.
Multiple margins can be named, to be defined in AA.MARGIN.TYPE Virtual
Table

T3TAAD - R18 85
86
 For a Deposit arrangement, when rates are negative the bank would collect interest
from the customer.
Tier Negative Rate - Negative Rates can be made applicable at the tier level
Yes – Indicates Negative rates can be given
No – Indicates Negative rates cannot be given (truncated to zero)
Block margin – Indicates when rate is negative, Margin cannot make the rate further negative
 Tier Amount
Relates to RATE.TIER.TYPE Field
Amounts can be entered if either BAND or LEVEL selected
 Tier Percent
Allows a percentage of the principal to be allocated a specific rate or be linked to a rate table
 Either Tier Amount or Tier Percentage can be opted for Band based calculation, not both
Until R17, Negative rate option was applied to control the overall rate arrived
from Interest product condition. From R17, tier level choice of negative rate is
possible.
TIER.NEGATIVE.RATE Field is used to set negative interest rates on accounts
in credit. Negative interest rates may occur either as a result of a negative rate
being specified or as the result of the rate minus any margin which is specified.
There are 3 options (YES, BLOCK.MARGIN and NO/NONE)
If the field is set as either “No” or “None”, then negative rates cannot be input
and if a rate becomes negative as a result of the application of a margin the rate
will be set to zero.
If the field is set as “Yes” negative rates can be input. If application of margin
makes the rate more negative, then that final negative rate will be used.
If the field is set as “BLOCK.MARGIN” then negative rates can be used, but the
following conditions apply:
- If the rate is positive and the margin makes the rate negative then the rate will
be set to zero
- If the rate is negative and the margin makes the rate more negative then the
margin will be ignored and the original negative rate will be used

T3TAAD - R18 86
We can calculate interest using a banded method where the bands are identified by a
percentage of the principal. This defines the percentage split of the interest band tiers.
TIER.AMOUNT Field - The tier amount relates to the field RATE.TIER.TYPE and
amounts can be entered if either BAND or LEVEL are selected.
Different interest rates can be defined for different amounts, indicating Level or Band
calculation.
TIER.PERCENT Field – This allows a percentage of the principal to be allocated a
specific rate or be linked to a rate table.
Different interest rates can be defined for different percentage amounts, indicating Level
or Band calculation.
System will allow band based interest calculation on TIER.PERCENT or
TIER.AMOUNT, but not both.

T3TAAD - R18 86
87
Interest Day Basis

To calculate interest based upon several different day basis types. Each T24 Interest Day Basis type
is represented as a numerator and denominator
A (360/360); B (366/360); C (366/366); D (360/366); ……
Accrual Rule
Include first day for interest accrual or Include last day for interest accrual or Include first and last
days for interest accrual
Compounding - DAILY, WEEKn, Mnn, TWMTH, Nnnn
PAYMENT.MODE – ADVANCE - When set, interest would be billed at Period Start
Calculation Threshold - Minimum balance to be maintained below which interest will not be
calculated
Negative Rate – Choice for negative rates for overall interest rate of the arrangement can be set
Slide 87
AA uses the INTEREST.DAYS.BASIS for determining numerator and

denominator for interest calculations.
The Accrue activity calculates the accrued interest amount up to the effective
date and posts the amount using the associated accounting rule.
Interest could be set to compound every day, weeks (say every week, every 2
weeks etc); monthly (every nMonths); twice a month and specified number of
times in a year.
Compounding not allowed when Interest is banded.
Payment mode can be set to Advance. When set, interest would be billed at
Period Start.
In order to have a discounted arrangement where interest is paid in advance,
Payment mode in interest condition has to be set as advance and the payment
type calc method should be advance. The payment type is discussed further in
payment schedule product condition.
CALC.THRESHOLD Field is used to specify that interest will be calculated

only if a minimum balance as mentioned in threshold is suppressed.
NEGATIVE.RATE Field is used to set negative interest rates on arrangements

T3TAAD - R18 87
with credit balance. Negative interest rates may occur either as a result of a negative rate
being specified or as the result of the rate minus any margin which is specified. Option
Yes would allow negative rates, Option No would truncate the rate to zero when the
calculated rate is negative. Option Block margin would block the rates from becoming
further negative as a result of the margin (when the calculated rate is negative)
This choice is related to the whole interest property and any of its derived rates

T3TAAD - R18 87
Interest – Product Condition Slide
88
88
 When a Deposit is used as a Collateral for a Loan/Overdraft Account, Loan/Overdraft

Interest rate can be tied to the Deposit’s Rate, applying additional margin at the OD
Account level.
 Linked Rate set to YES indicates the rate for a given tier be ‘Linked’ to the ‘Linked
Arrangement’
 Linked Arrangement - the Arrangement to be linked for calculating the Interest Rate
 Linked Property - Interest Property of the Linked Arrangement that should be referred
to, for getting the Interest Rate.
 Where at least one tier is set to be ‘Linked Rate’, Linked Arrangement and Linked
Property must be specified.
 For each tier that is specified as ‘Linked’, system would use the Linked Rate, treat it as a
‘Base’ rate, apply any Margin specified and calculate the Effective Rate for the Overdraft
Account
Where a Deposit is used as a Collateral for a Loan/Overdraft Account, there is a

need to tie the Loan/Overdraft Interest rate to the Deposit’s Rate and then
apply additional margin at the Loan/Overdraft Account level.
Linked Rate (Spread Rate) can be set as YES to indicate that the rate for a given
tier be ‘Linked’. This can be mixed with normal rate calculations as well.
Linked Arrangement - Where at least one tier is set to be ‘Linked Rate’, the
Arrangement to be linked for calculating the Interest Rate, must be specified
here (or automatically defaulted by the system, where a Limit is attached)
Linked Property - specifies the Interest Property of the Linked Arrangement that
should be referred to, for getting the Interest Rate.
Where at least one tier is set to be ‘Linked Rate’, Linked Arrangement and
Linked Property must be specified.
For each tier that is specified as ‘Linked’, system would use the Linked Rate,
treat it as a ‘Base’ rate, apply any Margin specified and calculate the Effective
Rate for the Loan/Overdraft Account.

T3TAAD - R18 88
Interest – Product Condition Slide
89
89
 Target Arrangement needn’t have any knowledge of the linked arrangement’s balance
or its tier conditions or Source Calculation/Source Balance setup.
 Target arrangement will get the rate from a single Source Arrangement and treats it
as the ‘Base’ rate – This is the rate at which the Linked Arrangement will accrue
interest for whatever its current balance
 In case the Source arrangement with a Banded tier condition, the rate returned will be
a pro-rated/blended rate
 Interest changes events on the source arrangement will result in a change of interest
rate on the Target arrangements
 Where there is a Limit attached to the Target arrangement and the Source
arrangement is configured as Collateral to that Limit, then on the Target arrangement,
system will try to default the Source arrangement reference from the Collateral
 Error is raised when there is more than one collateral right or collateral attached
For each tier that is specified as ‘Linked’, system would use the Linked Rate,
treat it as a ‘Base’ rate, apply any Margin specified and calculate the Effective
Rate for the Loan/Overdraft Account. This would be the rate at which the Linked
Arrangement is accruing interest for whatever its current balance. In case the
Deposit has a Banded tier condition, the rate returned will be a pro-
rated/blended rate. The Loan/Overdraft Account takes it as a single Source rate
from the Deposit Arrangement and treats it as the ‘Base’ rate
Any change in interest rate in source arrangement due to user triggered change
interest activity or periodic rate reset or basic interest or change in principal tier
due to partial withdrawal would result in a change of source arrangement rate.
When the event is effective back dated, there will be concomitant adjustments
on the Target arrangements.
Where there is a Limit attached, and at least one of the tiers in the Interest
condition is set to be ‘Linked Rate’, system will try default the Linked
Arrangement reference through Limit -> Collateral Right -> Collateral. If there is
more than one Collateral Right attached to the Limit, then an error will be
raised. If there is more than one Collateral under the Collateral Right, then an
error will be raised.

T3TAAD - R18 89
Features Linked Interest Rates 90
90
 Possible to tie the Penalty Interest of a Loan/Overdraft Arrangement to its own

Principal Interest/Debit Interest +/- additional margin for the Penalty Interest.
 When the source arrangement matures, the base rate will be 0 and further accruals in
target arrangement would be on 0+margin indicated.
 When the Source arrangement specified in collateral module has more than one
target arrangement linked, then user has to delink those arrangements and then come
to the Collateral screen to change the Arrangement Reference.
 If Limit is available on a future date, System raises an override - default the source
Arrangement from the Limit>Collateral would be on the respective Date
 Note, Target arrangement and Source Arrangement have to be in same currency -

Alternate property setup in Activity Restriction cannot be applied - The target
arrangement in one link cannot act as the source arrangement for another link
1. It is possible to tie the Penalty Interest of a Loan/Overdraft Arrangement to

its own Principal Interest/Debit Interest +/- additional margin for the Penalty
Interest using this feature.
2. When the Source arrangement matures, then it results in a Change of
interest rate on the linked arrangements – in this case, effectively making the
source rate as 0.
3. A Loan/Overdraft Account can be linked to a deposit arrangement for
interest rate purposes, will also allow this on multiple Loans/Overdraft
Accounts linked the same Deposit arrangement (by way of linking multiple
Limits to the same Collateral Right).
If an arrangement specified in COLLATERAL module has one or more
arrangements tracking it for Interest purposes, then it will not be possible to
simply change the Arrangement reference from the COLLATERAL record. User
would have to delink those arrangements and then come to the Collateral
screen to change the Arrangement Reference.
Limitations to Linked interest rates

Multiple Collaterals attached to the same Limit
The Deposit/Collateral, Limit and Loan/Overdraft Account cannot be in
different Currencies

T3TAAD - R18 90
Alternate Deposit Interest property if applied as a result of Activity Restrictions’
Property Rule Evaluation.
The source to target link is allowed upto only one level. i.e., a Loan Arrangement which
tracks a Deposit Arrangement cannot be specified as a Source to another arrangement.

T3TAAD - R18 90
Interest – Other features 91
91
 Each interest component is represented by an Interest Property
 Accrue - Calculates accrued interest, posts amount using associated
accounting rule
 Periodic Reset
 Fixes the rate according to current Periodic Interest conditions
 May cause interest recalculation and change to payment schedule
 Scheduled or manual
 Change
 Manual change to any of the Interest attributes may cause interest recalculation, may
cause Payment Schedule to change
 Floating rate
The Interest Property Class is used for all interest definition and processing in
AA. A T24 product defined and processed in AA can have multiple interest
properties defined. The number of interest properties is determined by the users
defining the products. The Interest Property Conditions are currency specific.
The Accrue activity calculates the accrued interest amount up to the effective
date and posts the amount using the associated accounting rule.
PERIODIC.RESET Field indicates the reset period of the index stated. System
would automatically reset the PERIODIC.RATE at the frequency stated in this
field. Periodic index may still be used without this field, it does not reset the
computed rate.
Changes to any of the Interest attributes may result in interest to be recalculated
and may cause updation of Payment Schedule.
Suppress Accrual Field accepts the options 'YES' or 'ALTERNATE'. Indicates
whether accruals needs to be Suppressed or Accrual should be done for the
Alternate Interest Property.
For Example: It will be set as YES by the system if the DONOR.ACCRUAL
field is set as SUPPRESS for any product / arrangement in
INTEREST.COMPENSTION property of a Bundle arrangement.
If it is set as 'ALTERNATE' for a property then the Accrual will be suppressed
for the property for which it is set and Accrual will happen for the Alternate

T3TAAD - R18 91
property which is set in Activity Restriction.
Blank value in this field denotes that there is no suppression of accrual

T3TAAD - R18 91
Interest – Advance Rate fixing Floating 92
92
 Interest linked to Floating rates uses Basic Interest table
 From R17, New rates with future effective date are effective on the same day
 Interest and Payment Schedule should be set as Forward dated property
 BI rate change in future date triggers APPLY.RATE-INTEREST activity for COB
 Creates forward dated Interest condition for each BI forward dates

including existing ones
 Payment Schedule is recalculated for revised rate based on set-up
 Calculates schedules for each of the BI forward dates including existing

ones
 Activity messaging can be configured to notify the customer ‘X’ number of days
in advance to actual change
From R17, For floating rate is linked to Arrangements, new rate released in Basic Interest table
with future effective date will be updated to arrangement on the same day for future effective
date.
For example, let’s assume, floating rate index increases effective 1- Mar-17 on 1-Jan-17 . On 1-
Jan-17 COB, new rate is updated in all the arrangements following the floating rate index
effective from 1-Mar-17. The new payment amount for the forward effective date is also
calculated based on the setup in payment schedule (using on Activity and Recalculate fields).
Note that this is applicable only when Interest property and Payment Schedule property are
Forward dated property
When a new record is created in BASIC.INTEREST (BI) table for a future date, the ‘Change
Interest’ activity will trigger the ‘Apply Rate’ activity for today’s date. This will create a
forward dated Interest condition, which is effective from the future effective date of the BI
record i.e. date on which the rate has to take effect. In our case, COB processing of 1-Jan-17
triggers ‘DEPOSITS-APPLY.RATE-INTEREST’ with effective date as today and with a
forward dated condition effective from 1-Mar-2017. This results in 2 interest conditions created,
first effective from 1-Jan-17 an another effective from 1-Mar-17.
This activity will also create a forward date condition for payment schedule in order to calculate
and store the new payment amount for the revised rate. This is based on the user configuration in
payment schedule with respect to recalculation of payment amount or term. Apart from creation
of forward dated interest condition, system will also create forward dated conditions for
Payment schedule for the same effective dates.
Activity messaging property class can be configured to notify the customer ‘X’ number of days
in advance to actual change. The handoff information for the notice would be: Old Rate as of
pre-notification date, New Rate as of forward date, Effective date of Rate change, Old Payment
Amount, New Payment Amount, Effective date of New Payment Amount.

T3TAAD - R18 92
Workshop – FLOATING INTEREST settings 93
93
 Use Admin Menu > Product Builder > Product Conditions > INTEREST
Create a new Product Condition for floating interest type
Use BASIC.RATE.TEXT key for floating interest
A default margin of 0.5%, negotiable but not below 0.25%. Also make the upper limit
0.75% but can be allowed beyond with an override

Minimum and Maximum rates are 7% and 9% respectively
Use Interest Day Basis “C”
Interest accrual to include Last Day
Tier Type is SINGLE
Negative interest effect due to margin not allowed
Attributes are negotiable by default
Create an Interest Product condition with type as floating.

T3TAAD - R18 93
94
In this workshop, we will see how to create an Interest Product condition with
type as floating.
Use BASIC.INTEREST Table 1
Single margin operand is Add with a default margin of 0.5%,
Minimum and Maximum rates are 7% and 9% respectively,
Tier Type is SINGLE,
Use Interest Day Basis “C”,
Interest accrual to include Last Day,
Negative interest effect due to margin not allowed,
Margin is negotiable but not below 0.25%. Also make the upper limit as
0.75%, can be allowed beyond with an override,
All Attributes are negotiable by default.

T3TAAD - R18 94
Workshop - Periodic Interest settings 95
95
 Use Admin Menu > Product Builder > Product Conditions > INTEREST
Create an Interest Product Condition with the following features:

Use Periodic Interest Table 90
Interpolate when Deposit Term is between specified periods
Periodic Reset should happen automatically every two years
A default margin of 0.50%, negotiable down to 0.25% with an override if exceeded.
Cannot be negotiated beyond 0.75%

Negative interest can be input or negative margin can make the final rate more
negative
Use Interest Day Basis Table A
Interest accrual to include First Day
Tier Type is SINGLE
PERIODIC.PERIOD and PERIODIC.RESET are the only other negotiable attributes
Create an Interest Product condition with type as Periodic.

T3TAAD - R18 95
96
In this workshop, we will see how to create an Interest Product condition with
type as Periodic.
Set the following conditions:
Use Periodic Interest Table 90
Interpolate when Deposit Term is between specified periods,
Periodic Reset should happen automatically twice a year,
Single margin with Add operand for a default margin of 0.50% ,
Tier Type is SINGLE,
Use Interest Day Basis Table A ,
Interest accrual to include First Day,
Negative interest can be input or negative margin can make the final rate
more negative,
Margin negotiable down to 0.25% with an override if exceeded. Cannot
be negotiated beyond 0.75%,
PERIODIC.PERIOD and PERIODIC.RESET are the only other
negotiable attributes.

T3TAAD - R18 96
AA.SOURCE.CALC.TYPE 97
97
 For property classes which require Source balance amount for

calculation, AA.SOURCE.CALC.TYPE record can be used to specify how the balance
amount can be determined.
The calculation source can be the arrangement balance or the activity information
 Source balance can be Debit Balance / Credit Balance or Both
 Source calculation Type can be Daily, Average, Highest, Lowest for balances,
Transaction count or amount for the activity
 For a Deposit arrangement Interest could be calculated on the Credit balance daily
or monthly based on the requirement though not restricted to it.
 Charges can be calculated based on the Balance or Activity information.
For property classes which require Source balance amount for

calculation, AA.SOURCE.CALC.TYPE record can be used to specify how the
balance amount can be determined.
The calculation source can be the arrangement balance or the activity
information. Source balance can be Debit Balance / Credit Balance or Both.
Source calculation Type can be Daily, Average, Highest, Lowest for balances,
Transaction count or amount for the activity.
Interest property class supports Daily , Highest, Lowest and Average
calculations or a user defined routine can be used to return the balance amount.
Daily – interest calculation based on the value dated balance (not supported for
CHARGE), Average – average balance over the interest or charge period,
Highest – the highest (in absolute terms) balance over the entire interest or
charge period, Lowest – the lowest (in absolute terms) balance over the entire
interest of charge period.
For a Deposit arrangement Interest could be calculated on the Credit balance
daily or monthly based on the requirement though not restricted to it.
Charges can be calculated based on the Balance or Activity information.
In the file AA.SOURCE.CALC.TYPE, the fields CALC.START.DAY and
CALC.END.DAY are used to define the day in each calculation period which is
the range to be considered to apply the calculation type. Also the interest may or
may not be applied for arrangement opened or closed mid month. These two

T3TAAD - R18 97
features are more applicable for the Accounts product line though its not technically
restricted to the same.

T3TAAD - R18 97
AA.SOURCE.CALC.TYPE Slide
98
98
We can see that the Daily Credit balance is used as source calculation type for
Interest and transaction amount is source calculation type for the charge on the
Deposit Product.

T3TAAD - R18 98
Tax Property Class 99
99
Payment
Customer
Schedule
Account Closure
Deposits
Activity
Officers
Restriction
Tax Accounting

TAX Property class can be used by all Deposit AA products. It allows

computing tax on INTEREST and CHARGE property classes or any of the
properties associated with these property classes. Tax can be defined either at
property class level or at property level. For example, a value INTEREST in the
field PROPERTY.CLASS will indicate if a deposit product has one or more
properties of INTEREST property class (deposit interest, commission) and tax
will be calculated for each of these properties. The corresponding tax code is
entered in field TAX.CODE which holds value from TAX table or
TAX.TYPE.CONDITION . If the user wants to restrict tax to any of the properties
of the product, this can be achieved by entering the property in the field
PROPERTY and corresponding values in PROP.TAX.CODE and
PROP.TAX.COND. Only INTEREST and CHARGE property classes or its
associated properties can be defined. It is mandatory to specify a value either in
TAX or a TAX.TYPE.CONDITION for the property class / property.

T3TAAD - R18 99
Tax – Property Class 10
0
100
 Multiple Tax properties allowed
 Currency and Dated
Attributes Types Property

DATED, CCY, MULTIPLE Class for
Balance TAX
Prefix
DUE, AGE
Tax property is currency based, dated and can be multiple. It is possible to

define Property on which Tax to be calculated and the corresponding tax code
and Tax type condition for the corresponding tax property. Tax property can be
allowed to be defined Property specific and Property class specific.
Bill is updated with Tax amount and Tax property for the corresponding Interest
or charge property. Tax cannot be scheduled. When a scheduled property has tax
to be calculated for that property, tax property and amount is displayed in
enquiry.
Customer based Tax is defined through TAX.TYPE.CONDITION table.
At arrangement level, it is possible to remove the values of TAX or
TAX.TYPE.CONDITION defaulted from the product level allowing for zero/no
tax calculation.

T3TAAD - R18 100
TAX – Product Condition 10
1
101
 Property Class
 Tax can be collected currently for Interest and Charge
 Tax Code
Tax table with rate for computation of tax for associated property class
Either TAX.CODE or TAX.CONDITION allowed
 Tax Condition
Valid TAX.TYPE.CONDITION
Either TAX.CODE or TAX.CONDITION allowed
Possible post separate entries of interest and charges separate from tax or net the
entry together.
PROPERTY.CLASS – Property Class on which tax can be collected for the

product is indicated here. Currently, only two property classes are allowed –
Interest and Charge.
TAX.CODE – this field has a value that has reference to the TAX table. It
indicates the rate to be used for computation of taxation for the associated
Property class.
Either TAX.CODE or TAX.CONDITION are allowed.
TAX.CONDITION - this field accepts a valid TAX.TYPE.CONDITION to
calculate TAX for the associated Property class. Either TAX.CODE or
TAX.CONDITION is allowed.
From R15, In order to provide the bank an option as to how Tax amount has to
be accounted accounting property class captures whether ‘Net’ or ‘Itemized’
accounting to be done.

T3TAAD - R18 101
TAX – Product Condition 10
2
102
 Property
Property on which Tax is calculated
Tax can be collected currently for Interest and Charge properties
 Property Tax Code

Tax table with rate for computation of tax for associated property class
Either PROP.TAX.CODE or PROP.TAX.COND allowed
 Property Tax Condition

Valid TAX.TYPE.CONDITION
Either PROP.TAX.CODE or PROP.TAX.COND allowed
Possible post separate entries of interest and charges separate from tax or net the
entry together.
PROPERTY – Properties on which tax can be collected for the product is

indicated here. Currently, INTEREST and CHARGE related Properties are
allowed.
If defined, the associated PROP.TAX.CODE and PROP.TAX.COND shall take
precedence over TAX.CODE and TAX.CONDITION for the related
PROPERTY.CLASS.
PROP.TAX.CODE – this field represents a reference on the TAX table which
will indicate the rate to be used for computation of taxation for the associated
Property
Either PROP.TAX.CODE or PROP.TAX.COND can be allowed.
PROP.TAX.COND - this field accepts a valid TAX.TYPE.CONDITION to
calculate TAX for the associated Property class. Either PROP.TAX.CODE or
PROP.TAX.COND is allowed.
From R15, In order to provide the bank an option as to how Tax amount has to
be accounted accounting property class captures whether ‘Net’ or ‘Itemized’

T3TAAD - R18 102
accounting to be done.

T3TAAD - R18 102
Tax split for customer
103
 Possible to split tax between customers using AA.CUSTOMER.ROLE or

CUSTOMER.RELATIONSHIP
 Possible to split tax between customers using CUSTOMER.RELATIONSHIP – the

percentage of split can be indicated for primary and joint customer.
 Customer relationship ID to be indicated in SAM for tax split
 T24 generates and reports tax entries by portfolio or group them to categorize
by customer relationship
ST.CUST.RELATIONSHIP.DATES - list of dates for a customer relationship record. ID
being customer relationship ID without the date
ST.TAX.REPORT.DETAILS - Tax report file to store customer-wise tax details against

a single transaction
Slide 103
From R14,
Customer Relationship can define the percentage split of income/tax amongst
the primary and joint customer. Tax splits are calculated between the various
joint holders based on the tax types linked to them. Tax Type to have Apply Split
as yes and Tax parameter to be available.
AA enables the tax calculation based on the customer relation for a customer
having a portfolio reference. T24 splits the tax calculated on an income for a
primary customer amongst the primary and joint customers in a pre-defined
percentage as indicated in the Customer Relationship.
ST.CUST.RELATIONSHIP.DATES - list of dates for a customer
relationship record. ID being customer relationship ID without the date
ST.TAX.REPORT.DETAILS - Tax report file to store customer-wise tax

details against a single transaction
Customer Relationship can be setup using CUSTOMER.REL.GROUP and
CUSTOMER.RELATIONSHIP (percentage share given here). Tax Type to have
Apply Split as yes and Tax parameter to be available.
CUSTOMER.RELATIONSHIP has to be indicated in the SEC.ACC.MASTER
(portfolio). The tax applicable for the arrangement is split between the owners

T3TAAD - R18 103
and splits are seen in ST.TAX.REPORT.DETAILS.
From R16,
AA.CUSTOMER.ROLE is released where tax splits are possible between customers.
It can be enabled at New arrangement activity and also using AA.CUSTOMER.ROLE.

This has been covered earlier under Customer property class

T3TAAD - R18 103
Proportional Calculation of Tax 10
4
104
 Regulatory Requirement might enforce proportional calculation of tax

 Change in the Tax Rate during the current Interest Payment period, it would
then split the Interest earnings by Tax Rate Change periods and calculate Tax
proportional to the Interest earned within each of those periods.
 Configured in TAX.CODE.PARAMETER at tax code level
Driven by a Regulatory Requirement the T24 Tax Engine and AA have been
enhanced from R17 to support Proportional Tax Calculation.
If this is set, then when the Tax Engine detects a change in the Tax Rate during
the current Interest Payment period, it would then split the Interest earnings by
Tax Rate Change periods and calculate Tax proportional to the Interest earned
within each of those periods.
Optional parameter table TAX.CODE.PARAMETER has to be configured for the
tax code. The table accepts all the tax codes but the proportional tax split
currently works only on AA.

T3TAAD - R18 104
TAX.CODE.PARAMETER 10
5
105
 Optional configuration to switch on Proportional Tax Calculation for a given Tax

Code - Record ID : Tax code record ID (without the date)
 Proportional Tax Calculation when set to YES, Tax is calculated proportional to

the Interest accrued for each Tax Rate Change period
 ST.TAX.CALC.DETAILS will be maintained for the break down of Proportional

Tax calculated for a given Arrangement, for a given Interest Property for a given
Interest Payment Date when Update tax Details is set to YES.
Tax Code Parameter table is an Optional Configuration parameter table to

switch on Proportional Tax Calculation for a given Tax Code. The record id is Tax
Code (key to the TAX Table but without the Date).
Proportional Tax Calculation when set to Yes: Tax calculated proportional to the
Interest accrued for each Tax Rate Change period. Else Tax is calculated on the
Total Interest accrued for the Interest Payment period, based on the Tax Rate
applicable as of the Interest Payment Date.
A new table ST.TAX.CALC.DETAILS will be maintained for the break down of
Proportional Tax calculated for a given Arrangement, for a given Interest
Property for a given Interest Payment Date when Update Tax Details is set to
YES.
In the slide we can see the tax code parameter set up done with
ST.TAX.CALC.DETAILS to be updated for an arrangement.

T3TAAD - R18 105
ST.TAX.CALC.DETAILS 10
6
106
In the slide we can see the ST.TAX.CALC.DETAILS of an Deposit arrangement.

Tax calculation would work just the same way in any event that results in
Payment of Interest Scheduled Interest Payment, Redemption of Deposit,
Maturity of Deposit and Adjust Bill
TAX.CODE.PARAMETER table accepts all the tax codes but the proportional tax
split currently works only on AA.
Remember, Backdated tax rate changes will not trigger reverse replay on tax
already calculated while forward projections are possible. This proportional tax
is applicable on tax on interest but not on charges,
When we have Change of Ownership of the Arrangement or Change of Product
of the Arrangement or Change of applicable Tax bucket of the Owner of the
Customer, there could be a change in tax code applicable for arrangement
during interest period. System will only determine the Tax Code applicable as on
the Interest Payment Date and will look for any Rate Changes only under that
Tax Code
Proportional Calculation on Interest calculated based on Compounding Interest
instead of Simple Interest is supported but if the Tax Rate change happened
mid-period, then base amount is calculated on a pro-rated basis based on the
number of days. There would be minor differences because this Pro-rata would
be linear and not compounded.

T3TAAD - R18 106
Workshop - Tax on Deposit Interest 10
7
107
 Use Admin Menu > Product Builder > Product Conditions > TAX
 Tax to be collected on Deposit Interest
 Property for Deposit Interest is DEPOSITINT
 For withholding tax, property tax condition is DEPTAX
Create a new Tax product condition for collecting tax on Deposit Interest.

T3TAAD - R18 107
Workshop – Solution - Tax on Deposit Interest 10
8
108
In this workshop, we will see how to create a Tax Product condition for
collecting tax on Deposit Interest.

Tax to be collected on Deposit Interest.
Property for Deposit Interest is DEPOSITINT.
For withholding tax, property tax condition is DEPTAX.

T3TAAD - R18 108
Quiz 2 – True or False 10
9
109
Quiz
1. Periodic Reset for Interest is not allowed in AA
True
a)
False
b)
2. Each Tier amount can have different interest rate types and different
margins
True
a)
False
b)

T3TAAD - R18 109
Quiz 2 – True or False 110
110
Quiz 4. Calculation Threshold for Interest specifies the minimum interest

amount for an arrangement
True
a)
False
b)
5. AA Supports Negative interest
True
a)
False
b)

T3TAAD - R18 110
111
 Interest property Class
 Tax Property Class

T3TAAD - R18 111
112 112
112
Charges Setup

T3TAAD - R18 112
113

Parameters for Charges Setup
 Charge Property Class
 Different kinds of charges

 i. Activity Charges
 ii. Rule break charges
 iii.Scheduled Charges
 Charge override
 Periodic Charges

T3TAAD - R18 113
CHARGE and ACTIVITY CHARGES Property Classes 114
114
Payment
Customer
Schedule
Account Closure
Deposits
Activity
Officers
Restriction
Tax Accounting

Both CHARGE and ACTIVITY.CHARGES are optional Property Classes of

DEPOSITS Product Line.
Both are related and used to define the method of calculation of various
Charges.

T3TAAD - R18 114
Charge – Property Class 115
115
 Multiple Charge properties allowed
 Currency is optional
Attributes
Types Property
DATED, OPT.CCY, MULTIPLE,
TRACKING, Class for
FORWARD.DATED Balance CHARGE
Prefix
ACC, PAY, DUE, DEF
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.

T3TAAD - R18 115
Charge – Product Condition 116
116
 Charge Type
Fixed or Flat
 Charge amount should be set
 USD 50; GBP 30, etc
Calculated
 Calculated on specified balances

 2% on Transaction amount, 3% on Commitment amount, etc
 Charge Currency
Currency of charge property
Charge will be calculated for the charge property
Amounts calculated rounded based on Currency of CHARGE property
Can be different from currency defined in Id of the Product condition
 Tiered charges
 Level, Banded, Groups
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.
CURRENCY Field defines the currency of charge property. Charges will be
calculated for the Currency defined in this field. Amounts input in amount type
fields are rounded based on the currency defined in this field.
This field is mandatory input and will not be defaulted to local currency.
Currency defined in this field can be different from the currency defined in the
ID. If both the currencies are different, then an override will be raised.
If requesting currency is different from currency defined in this field, then base
amount will be converted to charge currency equivalent and charge amount will
be calculated. The final charge amount will again be converted to the requesting
currency equivalent. Conversion will be done using mid-rate.
TIER.GROUPS Field defines the method of calculation of charge amount for
the currency. This field will accept two values, BANDS or LEVELS.

T3TAAD - R18 116
117
 Calculation Type
 Flat
 Charge amount should be set - USD 50; GBP 30, etc
Percentage
 Calculated on specified balances - 2% on Transaction amount
Unit
 Multiplication factor to arrive calculating charge - USD 2 per transaction
 Charge Rate
Rate at which charge calculated
Mandatory for Percentage Calculation Type
 Charge Amount
Amount of charge
Amount will be multiplied when Calculation type is UNIT
Mandatory for Flat and Unit Calculation Type
 Minimum and Maximum Charge Amount can be set for each tier
 Cannot be input for Flat Calculation type
CALC.TYPE Field defines charge calculation type to be applied for charge

calculations. Accepts values FLAT, PERCENTAGE , UNIT.
FLAT - Amount defined in CHG.AMOUNT used for the associated tier set.
PERCENTAGE - Rate defined in CHARGE.RATE applied for the associated
tier set.
UNIT - Multiplication factor defined in CHG.AMOUNT 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.
TIER.MAX.CHARGE defines maximum charge amount to be applied for tier to
calculate charges. If charge calculated for this tier is more than the amount
defined in this field then maximum amount will be charge amount for this tier.

T3TAAD - R18 117
118
 Calculation Threshold
 Base amount below which charge amount will not be calculated
 Free Amount
 Deduction allowed on calculated charge
 e.g. reduce USD 10 from calculated charge
 User defined Charge Routine

Can be added to Activity Restriction / Activity Charges product condition
Useful when Banks desire different / complicated methods of charge calculations
 Cancel Period
 Used to indicate grace period for rebatable insurance
 Accrual Rule
 Determines the amortization start and end dates while creating EB.ACCRUAL record
CALC.THRESHOLD Field defines the threshold amount (base amount) below which charge amount will
not be calculated.
FREE.AMOUNT Field - if defined the final charge amount will be the calculated charge amount less the
amount specified in this field.
When complex charges have to be defined, a user-defined routine can be specified to determine the charge
amount. AA.LOCAL.CALC.CHARGE.AMOUNT routine is attached to the field CHARGE.ROUTINE to
calculate the charge amount. A sample calculation method: Interest is calculated on the deposit 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.
Say, a rule break charge with 15% tolerance for repayment is set, the base amount will be (4000 - 1500) =
2500. Charge routines in CHARGE Product Condition can be added to ACTIVITY.RESTRICTION
/ACTIVITY.CHARGES Product conditions.
From R15, it is possible to set rebate back the unamortised portion of the charge (insurance) in case of
payoff or cancellation of charge(insurance).
The amortization parameter can be set up for such charges using Accrual rule in Charge product condition
A grace period can be indicated to start the amortization of the charge. CANCEL.PERIOD in charge
product condition indicates this facility.
If the charge is cancelled within the grace period, the charge given back as a complete rebate to the
customer. When the charge is cancelled or the loan is paid off after this grace period the unamortized
portion of the charge would be given as a rebate provided it is indicated in the charge property type.
System would schedule a new activity to identify the end of the grace period

T3TAAD - R18 118
Activity Charges – Property Class 119
119
 Define charge property when specific activities take place

 It is DATED, FORWARD.DATED and TRACKING type
Property
Attributes Class for
Types ACTIVITY
DATED, TRACKING,
FORWARD.DATED CHARGES
Activity Charges control the application of charges when specific activities take
place in the life of an arrangement. During an activity, if permitted, user can
amend or delete any of the future conditions.

T3TAAD - R18 119
Activity Charges – Product Condition 12
0
120
 Activity attracting charge

Activity Id to be input
Must be a valid record in AA.ACTIVITY
Any number of activities can be defined
 Charge Property
Charge property triggered when activity is triggered
Charge property for each activity can be defined when more activities are charged
 Billing the charge

Charge can be billed on occurrence of activity
Can optionally be deferred by days after activity occurrence
 CHARGE.AUTO.SETTLE
Related to the Agency product line for automatic settlement of the agent commission to the agent account

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.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 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.
APP.PERIOD Field accepts a valid T24 period. This denotes the application
period for current application Method.
AA does not age any Activity charge bills that are due.
CHARGE.AUTO.SETTLE

T3TAAD - R18 120
Related to the Agency product line for automatic settlement of the agent
commission to the agent account

T3TAAD - R18 120
Activity Charges – other features 12
1
121
• Create New Arrangement

ACTIVITY BASED • Closure of a Deposit
• Redemption of a Deposit
• Links an Activity to a
Charge Property
Separate • Flat Charge
Property Class • Charge based on Balance
Type In
AA.SOURCE.CALC.TYPE
• Activity Charge Property
with its condition
In Product • Charge Property (linked to
Condition Activity Charge Product
Condition) with its
condition
You can charge specific Activities like creating a new Deposit, redemption of a
deposit or changing the term of a deposit.
There is a separate Property Class ACTIVITY.CHARGES, 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
redeem a deposit before maturity, the charge can be based on the deposit
amount.

T3TAAD - R18 121
Charge – Other features - Scheduled Charges 12
2
122
• Frequency defined
Defined in a Payment • Charge Property Attached
Schedule • Payment Schedule attached
to Product
• Flat Amount – Annual Fees

• Calculated on a base amount
Type of Charge • Base amount type defined in
AA.SOURCE.CALC.TYPE
• Depends on AA Account
Balance
• Payment Schedule Property
In Product with its condition
• Charge Property (defined in
Condition Payment Schedule) with its
condition
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 an annual
administration fee on the Deposit amount.

T3TAAD - R18 122
Charge – Other features - Break Rule Charges 12
3
123
Defined in specific
Product Conditions • Under Periodic Rules tab
• In Term Amount, decrease of

Based on failure of (Deposit) Term Amount in 1 year
Periodic Attributes by 10%
• Linked to a Charge Property
• Charge Property (defined in

In Product Periodic Rules tab) with a linked
condition defined
Condition • Fixed or calculated on a base
amount
You can specify periodic rules in specific Product Conditions. For example, in a
TERM.AMOUNT Product Condition, you can attach a Periodic Rule such that
the decrease in Deposit 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, for charges to be collected when the rule is broken. The charge
can be a fixed amount or calculated on a base amount.

T3TAAD - R18 123
Charge and Activity Charges – Other features 12
4
124
 Activity Charges
Charge applied when Activity is performed. e.g. Deposits Redemption charge
Can be billed or deferred or capitalised
 Scheduled Charges
Charge applied on a particular day according to payment schedule e.g. Deposits
Annual fee
Can be billed or deferred or capitalised
Rule break Charges

Charge applied when a periodic rule is broken
Periodic rules defined in certain product conditions
e.g. Restrict maximum number of redemptions per year
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.
a) When an Activity is processed, the property class ACTIVITY.CHARGES
defines the Activities which need to be charged.
b) We can define Periodical collection of Charges, where frequency and type are
defined in Payment Schedule.
c) A rule break charge can be levied when a Periodical Rule is broken. 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 Activity Charges product condition is used to specify
whether activity charge amount will be deferred or made due or capitalised.
PAYMENT.METHOD field in PAYMENT SCHEDULE product condition is
used to specify whether the scheduled charge amount will be deferred or made
due or capitalised.

T3TAAD - R18 124
5
125
 Charges can be collected or paid at a regular frequency using Payment Schedule
 For Deposits Arrangements, the schedule charges could be yearly, semi-annual,
quarterly or monthly. Charges can also be collected on Rollover or maturity as well.
 Charge Collected upfront can be amortised using Accounting Property class setup
- Amortisation period such as Renewal, a Fixed Period (like 3M) or Maturity
 PL to which the charges are booked and against which company is configurable.
 Charge can be accrued on linear basis in daily frequency. Charges collected on
schedule dates can be set to accrue until next schedule date
 Accounting Product Condition used to setup Charges Accrual and Amortisation
Charges can be collected or paid at a regular frequency using Payment Schedule

product condition.
Charge Collected upfront can be amortised using Accounting Property class
setup - Amortisation period such as Renewal, a Fixed Period (like 3M) or
Maturity
Charge Property can be accrued on linear basis in daily frequency. Charges
collected on schedule dates can be set to accrue until next schedule date.
At the time of Closure, the remaining unaccrued charge the same would be
accrued/capitalised.
Note that on a preclosure, charge for that period of preclosure will be dropped
(the charge would be cancelled).
The PL to which Charges are booked and against which company can also be
configured in Accounting property class
Accounting Product Condition allows us to define the Accrual and Amortisation
of charges.
Refer to Accounting Product condition for field level information to setup
accrual and amortisation.

T3TAAD - R18 125
Workshop – Fixed Charge Settings 12
6
126
 Use Admin Menu > Product Builder > Product Conditions > CHARGE

 Set the following rules
Fixed Charge of USD 100
 All Attributes are negotiable by default
Create a Charge Product condition for collecting a fixed charge.

T3TAAD - R18 126
Workshop Solution 12
7
127
In this workshop, we will see how to create a Charge Product condition for
collecting a Fixed charge.
A Fixed Charge of USD 100,

T3TAAD - R18 127
Workshop – Charge Condition Settings 12
8
128
Create a new Product Condition
Set the following rules
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
Create a Charge Product condition for collecting a calculated, banded charge.

T3TAAD - R18 128
9
129
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

T3TAAD - R18 129
Workshop 13
0
130
Charges in USD
No charges for transaction amount upto 5,000
Flat Charge of 100 for transaction amount upto 10,000
Flat Charge of 300 for transaction amount upto 30,000
Additionally 1.5% for transaction amount beyond 30,000and upto 50,000
with a maximum of 500
Additionally 1% for transaction amount over 50,000 subject to a maximum of
5,000
 Allow a rebate of 50 on charge amount
 All Attributes are not negotiable by default
Create a Charge Product condition for collecting a mixed, banded charge.

T3TAAD - R18 130
1
131
collecting a mixed, banded charge.
Set the following rules
Charges are calculated type and collected in USD
Tier groups are banded
Flat Charge of 100 for transaction amount upto 10,000
Flat Charge of 300 for transaction amount upto 30,000
Additionally 1.5% for transaction amount beyond 30,000and upto
50,000 with a maximum of 500
Additionally 1% for transaction amount over 50,000 subject to a
maximum of 5,000
No charges for transaction amount upto 5,000
Allow a rebate of 50 on charge amount

T3TAAD - R18 131
Workshop – Activity Charges Condition Settings 13
2
132
 Use Admin Menu > Product Builder > Product Conditions > ACTIVITY.CHARGES
Charge to be levied when a new Deposit is opened

The Charge Property is DEPADMINFEE
This New Deposit Fee to be made DUE on occurrence of activity
 All Attributes are not negotiable by default
Create an Activity Charge Product condition.

T3TAAD - R18 132
3
133
In this workshop, we will see how to create an Activity Charge Product

condition.
Charge to be levied when a new Deposit is opened,
The Charge Property is DEPADMINFEE,
This New Deposit Fee to be deferred for collection,
All Attributes are not negotiable by default

T3TAAD - R18 133
Charge Override Property Class 13
4
134
Payment
Customer
Schedule
Account Closure
Deposits
Activity
Officers
Restriction
Tax Accounting
Activity Activity Activity Charge

Presentation Mapping Charges Override
CHARGE.OVERRIDE Property Class enables a user to waive/modify charges,

when an activity is triggered or a rule is broken. If more than one charge is
attached for the same activity, user will be able to modify/waive all. Charges
triggered through transactions by FUNDS.TRANSFER and TELLER modules
cannot be waived.

T3TAAD - R18 134
Charge Override – Property Class 13
5
135
 This property is dated and non-tracking
Property appears in an arrangement after an Activity charge is triggered and

validated
Property Class for
CHARGE.OVERRIDE
Attributes
Types
DATED, NON.TRACKING,
TRIGGER
CHARGE. OVERRIDE property does not appear when the use 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.

T3TAAD - R18 135
Charge Override – Product Condition 13
6
136
 Charge Amount
User input activity triggers an activity charge / periodic charge
On committing the activity, system defaults charge amount in arrangement
 Charge Actual Amount

Value could be Null, Zero or a numerical value
Charges are waived completely if value 0 is input
Default charge as in CHG.AMT would be levied if this field is left blank
User can modify this charge by inputting a new charge amount, if left negotiable
 Waive Reason – Reason given by user for waiving charges is stored

If more than one charge for the same activity is attached, user can modify /
waive all
Charges collected during payout, redemption etc. cannot be modified or
waived
Fields relating to Actual and Waived charges can be viewed in
AA.CHARGE.DETAILS and AA.BILL.DETAILS
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.
It is necessary for the bank to know what is the waived charges and the reasons.
The reasons are stored in Waive Reason field
If more than one charge is attached for the same activity user will be able to
modify/waive all. Charges collected during payout or charges collected during
pre-closure / partial closure cannot be modified or waived as these pertain to
Activities created on account transactions from external applications.
In AA.CHARGE.DETAILS and AA.BILL.DETAILS, users can view the details
about the Default charge amount, Actual charge amount, and the waived charge
amount if any, with valid reasons

T3TAAD - R18 136
Periodic Charges Property Class 13
7
137
Payment
Customer
Schedule
Account Closure
Deposits
Activity
Officers
Restriction
Tax Accounting

Charges collected for an activity or for breaking rules can be deferred. Though
system calculates the charge it would not raise any bills or generate accounting
entries. PERIODIC.CHARGES Property Class is used to make these deferred
charges due.

T3TAAD - R18 137
Periodic Charges – Property Class 13
8
138
 This property is dated
 Currency is optional
Property Class for

PERIODIC.CHARGES
Attributes
Types
DATED, OPT.CCY
Balance
Prefix
PAY, DUE, DEF, AGE
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.

T3TAAD - R18 138
Periodic Charges – Product Condition 13
9
139
 INC.ALL.DEF.CHGS
On the scheduled date whether all the deferred charges to be made due
 DEFERRED CHARGE
Charge property that are deferred and to be made due can be multi-valued
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.
Both of the above mentioned 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 DEPOSITS-NEW-ARRANGEMENT and DEPOSITS-
APPLYPAYMENT-DEPOSIT.PAYOUT. 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.
MAX.CHG.AMOUNT.CR - Defines maximum charge amount to be paid for the

currency attribute if the net charge amount is a Credit.

T3TAAD - R18 139
MIN.CHG.AMOUNT.CR - Defines minimum charge amount to be paid for the currency
attribute if the net charge amount is a Credit.
Different charge groups can be defined in virtual table AA.CHARGE.GROUP. Charge

group specific free transactions can be given using the fields FREE.CHARGE.GROUP
and FREE.TXN.COUNT.
Possible to give package where free transactions can be specified per group in
multivalue set Or free transactions for a particular group by indicating
FREE.TXN.COUNT for the group as ALL.
Remember charge group can be defined only for those charges which are calculated
based on activities and if left empty denotes no free transactions for any group.

T3TAAD - R18 139
Quiz 3 - Match the Following 14
0
140
Activity Charge
1. a) Not Currency dependent
Scheduled Charge
2.
b) DEPOSITS-NEW-
ARRANGEMENT
Break Rule Charge

3.
c) Payment Schedule
Charge Property Class

4.
d) Currency dependent Optional
e) Periodic Rules
Activity Charge Property Class
5.

T3TAAD - R18 140
1
141
 Charge Property Class
 Different kinds of charges

 i. Activity Charges
 ii. Rule break charges
 iii.Scheduled Charges
 Charge override
 Periodic Charges

T3TAAD - R18 141
14 14
2 2
142
Bills
Expected funding and
Repayment/Redemption
Setup

T3TAAD - R18 142
3
143

Parameters for Bill Generation and Payments
 Payment Schedule Property Class
 Settlement Property Class
 Payment Rules Property Class
 Payout Rules Property Class
 Activity Mapping Property Class

T3TAAD - R18 143
Payment Schedule Property Class 14
4
144
Payment
Customer
Schedule
Account Closure
Deposits
Activity
Officers
Restriction
Tax Accounting

PAYMENT.SCHEDULE is a mandatory Property Class of DEPOSITS Product

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

T3TAAD - R18 144
Payment Schedule – Property Class 14
5
145
Defines Rules for paying Interest, paying Principal and collecting Charges for a
Deposit product
 Property can be viewed and values can be edited
 Product condition is Dated, Forward dated Property

and Currency specific Class
PAYMENT.
SCHEDULE
Attributes
Types
DATED, CCY,
FORWARD.DATED
Each Deposits T24 product will mandatorily have a PAYMENT SCHEDULE

Property defined, and its Product Condition is Currency dependent.
The AA payment schedules have various flexible and useful features. During an
activity, if permitted, user can amend or delete any of the future conditions. In a
Payment Schedule the interest to be paid to the customer can be scheduled so
that on the payout date system would create the pay bill. User can define
payment schedule which will have options pay and due payment type. For
example, the bank may collect charges from the customer, say, on a yearly basis,
this would be due from the customer. Bank would pay interest on deposits to the
customer which would be payable type.
From R15, Forward conditions can be effective dated based on Anniversary,

Start date or Arrangement date at the Product designer level – If negotiable the
values can be amended at arrangement level. You may recollect that this
discussed in AA Core courseware already.

T3TAAD - R18 145
Payment Schedule – Product Condition 14
6
146
 Payment Types:
ACTUAL - Repayment of calculated property classes - Interest, charge

DEPOSIT.PRINCIPAL – Automatic Deposit Funding for system calculated amount
 DEPOSIT.SAVINGS – can be used for regular funding of deposit
Payment Methods :
DUE - Amount is Due to or from customer
CAPITALISE - Capitalise the amount
 PAY – Amount paid to customer
MAINTAIN – Actual amount to be maintained for rollover
 Payment Mode : Advance - Discounted Interest
PAYMENT.TYPE Field denotes different types of calculated payments that

could be applied. Should be a valid record in AA.PAYMENT.TYPE File.
Constant – results in equal repayments. This requires both a Term Amount
repayment (Account property) and Interest repayment (Interest property) to be
specified.
Linear – Term Amount repayment remains fixed over the life of the
arrangement. Optional properties such as Interest, Charge, and Tax may be
included. The actual amounts calculated by these properties will be added to the
fixed Term Amount repayment. Both Constant and Linear may be used if there
is interim Payment of funds – say Account funds has to be paid out on a regular
basis.
Actual – is used for repayment of calculated property classes (i.e. Interest,
Charge, and Tax) and will be determined on each payment schedule date.
PAYMENT.METHOD : Once the Payment Type is specified, user can specify
whether the amount will be Due (to or from the customer) or Capitalised. Other
options are:
PAY – when interest has to be paid to Customer, this will be set to PAY. On
payment date, system will debit accrual category and credit PAY (Interest
property). MAINTAIN – Specifies the actual to be maintained for Rollover
purpose. On the Renewal date, user has an option to Rollover the outstanding

T3TAAD - R18 146
principal amount or part of it. This is achieved through option MAINTAIN.
From R15, PAYMENT.MODE field introduced can be set to “ADVANCE“ for set of
advance interest payment. Interest property class is mandatory and only possible to input
in this payment mode setup.
Note a setting in Interest product condition was also discussed earlier for interest to be
billed upfront.

T3TAAD - R18 146
7
147
 Payment frequency
Frequency at which payments will be made due
Applicable for Payment Type
 Payment frequency is defaulted when due frequency is null
 Deferred Periodic Charges defined in Payment Schedule
PAYMENT.FREQ field indicates frequency at which payments will be made

due. Example:
a) M 01 31. M = Monthly. 01 = one monthly intervals. 31 = the last day of the
month, b) M 03 31 M = Monthly. 03 = three monthly intervals. 31 = the last day
of the month. c) M 01 10 M=Monthly, 01 = at monthly intervals10 = 10th of the
month, d) 31 MAR 2010 W , where W= weekly. In this case, the first schedule
would fall on 31March 2010 e) 31 Mar 2010 BSNSS, where BSNSS = every
business day. In this case, the first schedule would fall on 31March 2010.
Deferred Periodic Charges need to 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 activity for all the Deferred charges that are yet to be collected.

T3TAAD - R18 147
Payment Schedule – Product condition 14
8
148
 DEFER.PERIOD – Payment type part of schedule
can be deferred. Defers the due date of the bill
 Bill is generated for same value, however
deferred for specified number of days
before due, maintain, pay or capitalise
 Bill status is DEFER for the deferred period
 balance prefix is DEF
 AA.ACCOUNT.DETAILS
stores the defer dates for
the bill.
From R15, Deferring a bill is possible using payment schedule.

DEFER.PERIOD indicates the period for between the original schedule date and
the required make due date which is going to happen.
Note that the bill is generated as before for the same value, however its deferred
some days before making it due or pay or capitalizing the same.
Defer not allowed for Account property class and can be a valid period (D, W, M
or Y).
DEFER.REFERENCE stores the Arrangement Activity Reference of Defer
activity after the aging activity
Note that the same payment type cant be used twice in payment schedule
condition when one of them is deferred.
Balances are moved to respective DEF Balance types on actual scheduled date
and Capitalisation/make due/pay/maintain happens on actual scheduled date +
defer date for the payment types having defer period in Payment Schedule.
Defer information is also stored in AA.ACCOUNT.DETAILS under the activity
for bill generation along with BILL.DATE
If present, this should be the date to consider for real make due/Aging if Age By
days is set.

T3TAAD - R18 148
The bills generated on the payment schedule is stored in AA.BILL.DETAILS.
When a bill is deferred the Defer date is updated in the AA.BILL.DETAILS based on the
DEFER.PERIOD in the payment schedule for the specific payment type.
The property specific original amount, outstanding property amount is indicated in the
bill. Any adjustments are also seen in the record.
Bill details have three sets of fields:

T3TAAD - R18 148
9
149
Actual amount - for ad-hoc payments, actual amount for each payment date
to be defined
 Overrides the calculated amount
 Start Date – Indicates actual payment start date

 Defaulted from Base date, if start date not indicated
 End Date - Indicates actual payment end date
 Number of Payments can be indicated instead of End date
 Start date and End date fields can accept not only an absolute date but also a
‘relative’ date
There can be two amounts for each payment definition; Calculated Amount and
Actual Amount.
ACTUAL.AMT - An actual amount can be entered by the user to override the
calculated amount or manual payments. When adhoc payments are defined we
need to define the actual amount for each payment date.
START.DATE - This field indicates the actual payment start date. If Start date is
mentioned then the payment frequency is applied on the start date. Else, it is
defaulted from the Base Date. Adhoc payment dates can be defined by
expanding the multivalue sets and defining the dates in the field START.DATE.
Payment and Due Frequency needs to be null. Additionally an End Date or
Number of Payments can be specified to indicate to T24 when the payments
should terminate.
END.DATE - This field indicates the actual payment end date.
We know that either an End Date or Number of Payments can be specified to
indicate to T24 when the payments should terminate.
NUM.PAYMENTS field- If a frequency has been specified the user can specify
either an End Date or Number of Payments to indicate to T24 when the
payments should terminate.
Both START.DATE and END.DATE fields can accept not only an absolute date
but also a ‘relative’ date.

T3TAAD - R18 149
Defining relative dates 15
0
150
 Relative date in Start Date or End Date field based on events:

START – Initial Deposit of arrangement
 MATURITY – Maturity of an arrangement
 RENEWAL – Renewal date for an arrangement
 Relative Start or End date for Start / Maturity / Renewal

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

T3TAAD - R18 150
1
151
 Recalculating Payment Schedule

Possible to be scheduled
Possible due to occurrence of certain activities
 Scheduled Recalculation
 Automatically at predefined frequency
 weekly, monthly, yearly, etc
 Activity to trigger recalculation like:

Update Charge
Change Interest
Change Term
Increase / Decrease Term Amount
You may need to revise your repayment schedule when loan amount, or interest
rate or term changes. You can specify which activity should result in
recalculation of repayment schedule.
ON.ACTIVITY Field to state a list of activities during which payment schedule
is to be recalculated. When those activities are performed, system would
automatically recalculate the payment schedule. For example, the following
Activity Classes may require a recalculation:
UPDATE – CHARGE, CHANGE – INTEREST, CHANGE–
PAYMENT.SCHEDULE, CHANGE.TERM – TERM.AMOUNT, INCREASE –
TERM.AMOUNT, DECREASE -TERM.AMOUNT. For each of these activities,
the resulting recalculation types must be specified in the associated field -
RECALCULATE.
More than one activity may be stated for recalculation. But there should be no
duplication. Should be a valid entry in AA.ACTIVITY file.
For a scheduled recalculation RECALC.FREQUENCY Field must be defined at
weekly, monthly, yearly frequency etc. If RECALCULATE Field has
recalculation type as ‘nothing’ for any of the activities, automatic recalculation
to be scheduled for this.

T3TAAD - R18 151
2
152
 Recalculation types
 Payment – payment amount will be changed
 Term – term of the arrangement will be altered
 Residual – residual amount will be changed
 Nothing – payments, term, and residual will be unchanged. Recalculation frequency

should be specified
 Progressive Payment – Increase / decrease in calculated amount
Recalculate field indicates which payment parameter to change when changes

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

T3TAAD - R18 152
3
153
 Bill Type indicates whether bill is produced for payment / information

Payment – Payments made to customer like Interest
Expected – Principal amount to be received from customer
Bill can be produced prior to due date - If interest is to be paid to customer on the
10th of every month and the bill is to be issued on the 9th, this field will be set as ‘1
 Combining due amounts into a single bill

When amounts become due on the same date
Notices are also to be issued on the same date
Either a single bill can be generated or bills can be split to allow payments from / to separate
accounts
Deferred bills also can be combined by the system but based on bill date, pay
date, defer date and payment method.
BILL.TYPE field- Indicates whether the bill is produced for payment or for
information only. For principal amount which is to be received from the
customer, the type will be EXPECTED (contingent balance) and for payments to
customer like interest payment types, it will be PAYMENT.
BILL.PRODUCED field– Indicates the number of working days prior to the due
date when the bill needs to be produced. E.g. if interest is to be paid to customer
on the 10th of every month and bill is to be issued on the 9th (previous working
day), this field should be set as 1.
When more than one payment falls due on the same date, user can opt for
combining the bills. For example, user can combine interest bill and charges
bill, which have the same frequency and fall on the same date.
Bills that are issued on the same date and will also become due on the same date
are typically combined into a single bill.
This bill will then contain the various components of the payment. This provides
for example, the ability to combine a monthly “annuity” deposit repayment
with a monthly charge to provide the user with a single bill amount.
BILLS.COMBINED Field is used to exercise this option of combining bills
falling on same date.
When bills are deferred Combining Bills will be possible only if BILL.DATE,
BILL.PAY.DATE, DEFER.DATE and PAYMENT.METHOD all are same.

T3TAAD - R18 153
4
154
 Billing
 Make due activity
 All due amounts are billed - Principal, interest and charges
 Bills are generated whether payment is scheduled or ad-hoc
 Generates bill on due date or in advance by a specified no. of days
 Chaser fee charge can be linked to the activity
 Different payment types can be specified for different periods

 Start Date and End Date for each period must be specified
 User can also specify amount of repayment
 When amount is manually input, system will not calculate repayment amount
In AA, Payment Schedules generate Bills when a scheduled amount is not

capitalised and made due. Unlike other T24 contract applications, when a
scheduled amount is made due, processing will not happen automatically. It has
to be processed outside AA. Bills for a payment, can be generated on the due
date or by specified number of days in advance by indicating number of advance
days in BILL.PRODUCED Field. Bills which are due are stored in
AA.BILL.DETAILS table. The bill will contain the details of the amounts due,
the due date, etc.
When payment frequency for a Bill, defined in the product condition is changed,
a bill already made due in the arrangement for a future date, remains unchanged.
All balances, whether principal, interest or charges, when they become due are
billed. Bills are automatically issued and made due during COB (Close of
Business) according to the schedule. A chaser fee charge can be linked to the
Issue Bill Activity.
Different payment types can be specified for different periods.

T3TAAD - R18 154
AA.BILL.DETAILS
155
Slide 155
The bills generated on the payment schedule is stored in AA.BILL.DETAILS.

When a bill is deferred the Defer date is updated in the AA.BILL.DETAILS
based on the DEFER.PERIOD in the payment schedule for the specific payment
type.
The property specific original amount, outstanding property amount is indicated
in the bill. Any adjustments are also seen in the record.
Bill details have three sets of fields:
BILL.STATUS takes the value ISSUED, DUE, AGING, SETTLED based on the
lifecycle of the bill – When the bill is deferred we have a BILL.STATUS with
value DEFER after being issued and before becoming DUE.
Note that When the bill is capitalised the bill is treated as settled.
The SETTLE.STATUS field is updated as UNPAID initially and when the bill is
settled it is REPAID. The AGING.STATUS takes the values like GRACE, DEL,
NAB etc and finally SETTLED. Note that GRACE, DEL, NAB values are based
on the overdue definition. We will read that EXP bills can be aged for Savings
Deposit products later in the course.
A interest payment to customer would be pay bill. Hence the bill status would
be ISSUED, PAY and Settled status will be UNPAID and REPAI
When bill is paid/made due in advance and the payment bill is generated but

T3TAAD - R18 155
paid after the cooling period if any. MAKEDUE.ADVANCE activity will be scheduled
one day after cooling period. Note that any interest changes, principal changes through
activity would affect the interest accordingly and final interest in Tot Due Amt of
AA.INTEREST.ACCRUALS. The difference would be paid or made due immediately.

T3TAAD - R18 155
Payment Holidays
156
Possible to stop generating bills for an interim period during the life of
arrangement
DEPOSITS-DEFINE.HOLIDAY-PAYMENT.SCHEDULE - calculates holiday payment

details for given payment type based on given definition.
Updates holiday payment dates in AA.ACCOUNT.DETAILS
Calculate payment amount honouring the holiday payment dates
Slide 156
The activity class for postponement of payment schedule dates is DEPOSITS-

DEFINE.HOLIDAY-PAYMENT.SCHEDULE. User can input the holiday
information
Holiday start date cannot be less than activity effective date. For Holiday start to
be backdated then the activity itself has to be run effective back dated.
In Case, Holiday Start date is future date then base date for holiday payment
calculation would be previous payment date of holiday start date.
If user wants to reverse the holiday definition then actual activity itself to be
reversed or He has to input another DEFINE.HOLIDAY activity with Number
of Holiday payments as Zero or he may delete the holiday payment type multi
value set.
Any amendments to the existing holiday payments definition should be done via
DEFINE.HOLIDAY activity.
If multiple holiday payment definitions with multiple start dates defined then
payment schedule projection would honour all of the payment holidays. There
may be few payments between holiday start dates.
When payment type is removed using Deposits-Update-PaymentSchedule
activity and left untouched in Holiday Multi value set, then it would be thrown
as an override message only when inputting new DEPOSITS-

T3TAAD - R18 156
DEFINE.HOLIDAY-PAYMENT.SCHEDULE activity.

T3TAAD - R18 156
Workshop - PAYMENT SCHEDULE Settings 15
7
157
Use Admin Menu > Product Builder > Product Conditions >
PAYMENT.SCHEDULE

Interest, at monthly frequencies, to be paid
Attributes are negotiable
Create a Payment Schedule Product condition for Interest only payments.

T3TAAD - R18 157
8
158
In this workshop, we will see how to create a Payment Schedule Product

condition for Interest only payments.
Interest, at monthly frequencies, to be paid,
Interest property to be used is ‘DEPOSITINT’,
All Attributes are negotiable.

T3TAAD - R18 158
SETTLEMENT Property Class 15
9
159
Customer Interest Charge Payment Rules
Settlement Payout rules
Account Closure
Deposits
Officers Payment Schedule
Tax Accounting
Activity Activity Activity Activity

Presentation Mapping Charges Restriction
The SETTLEMENT property class supports selected settlement requirements

for Lending, Deposits and Accounts arrangements. The settlement property
class enables the settlement of dues / payouts using another arrangement / T24
Account or creates DD.ITEM by providing DD.MANDATE.REF. From R14,
Transaction Recycling can be used to capture transaction which cannot and
should not be completed and retry them until they are completed or abandoned.

T3TAAD - R18 159
Settlement – Property 16
0
160
 Allows select settlement instructions for Deposits arrangements
 Links a mandate defined in the Direct Debit (DD) module to an

arrangement account
 Property can be viewed and values can be edited
 Product condition is Date specific
Attributes SETTLEMENT
Types
Property Class
DATED
SETTLEMENT Property class is DATED type.

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

T3TAAD - R18 160
Settlement of Dues / Payout 16
1
161
 Multi-value set of fields for Receive and Payout transactions
 Receive definition based on Payment Types and related activity
 Payout definition based on Property and related activity
 Arrangement reference as PAYIN.ACCOUNT / PAYOUT.ACCOUNT
 Enables settlement of dues / pay-out using another arrangement / account
 Can either be a T24 account or an arrangement account or payment order
 Default settlement account can be indicated for Payment and Payout

purpose using DEFAULT.SETTLEMENT.ACCOUNT
 PAYIN.ACTIVITY/PAYOUT.ACTIVITY - APPLYPAYMENT action only
Default Activity is considered from Activity mapping from R17
 PAYIN.SETTLEMENT field to be set as Yes
Settlement Property allows settlement of dues / pay-outs between an

arrangement and another arrangement / T24 account.
Receive definition is based on Payment Types and related activity while Payout
definition is based on Property and related activity.
Settlement property will function only if PAYIN.SETTLEMENT Field is set to
YES.
PAYIN.ACCOUNT (Receive) & PAYOUT.ACCOUNT (Pay) can either be a
T24 account or an arrangement account or Payment Order.
Default Settlement Account can be used to specify the Settlement Account
instead of having to repeat the same account reference across individual
settlement instructions. DEFAULT.SETTLEMENT.ACCOUNT is defaulted as
settlement account for all Payment and Payout when a Settlement Account,
Beneficiary or DD Mandate Reference is not defined.
Currently, pay-in settle activity and pay-out settle activity allows
APPLYPAYMENT action alone. From R17, PAYIN.ACTIVITY and
PAYOUT.ACTIVITY are not mandatory – When not defined system considers
the default credit and debit activity specified in activity mapping.

T3TAAD - R18 161
Settlement Instruction - Receive 16
2
162
 Meant for Funds coming into the Arrangement
Payment Type
Link between Payment Schedule and Settlement property
Can be sub valued for different types of Interest, Charges
Pay-In Settle Activity

Activity run to receive funds, only APPLYPAYMENT allowed
Refers to AUTO.SETTLE field of respective Payment Schedule
If set as Yes, fetches Settlement Account corresponding to Payment Type
Active – can be set as ‘No’ to:

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

T3TAAD - R18 162
Settlement – Receive funds 16
3
163
Could be either from a T24 ACCOUNT module (internal / nostro) or from a T24
Arrangement or from DD mandate
 Receiving Fund examples:

Funding of AA Deposit
Receipt of scheduled Charges
 Settlement for Activity Charges

 Grouped under payment type ACTCHARGES
 Refers to AUTO.SETTLE field of respective Activity Charges property
 If set as Yes, fetches Settlement Account corresponding to Payment Type
 Activity charges property designed to settle out of UNC first, if available
Funds can be received from either a T24 ACCOUNT (Customer / Internal /

Nostro) or from a T24 Arrangement or from a DD mandate. Examples of funds
received – Funding of AA Deposit, receipt of a charge.
All Activity Charges are grouped under the payment type ACTCHARGES.
Activity Charges looks in the Settlement Property for that payment type and
fetches the corresponding settlement instructions. The Settle Activity is defined
in Activity Charges PC. This settlement activity refers to the AUTO.SETTLE
Field of the respective Activity Charges property. If this field is set to YES, then
it will look up the Settlement property and fetch the settlement account
corresponding to the same payment type.
Please note that Activity Charges property is designed to run the activity to settle
out of UNC first, only when there is remaining outstanding to be settled, it will
go to the settlement property, provided the Auto Settle field is set to YES.

T3TAAD - R18 163
Settlement – Receive funds – ACCOUNT.DEBIT.RULE 16
4
164
 Insufficient funds in Account indicated for a Payment Type
 Settlement process controlled by ACCOUNT.DEBIT.RULE
 Pay-In rule Field has values Full, Partial, None
 Full – Whether or not funds available, debit Pay-In account with full bill amount
 If funds available partially, overdraft created for short amount
 Partial – Pay-In account debited only to extent of funds available
 None – Pay-In account not debited unless funds are available to settle the bill in full
During the settlement process, the account specified to settle bills may or may
not have sufficient funds for the purpose. Values FULL, PARTIAL and NONE in
the PAYIN.RULE FIELD controls the settlement process in such cases, using
the ACCOUNT.DEBIT.RULE.
FULL: Irrespective of the fact, whether or not funds are available in the
specified account, system debits the Pay-In account to the extent of the bill
amount. If funds are only partially available, system creates an overdraft in the
Pay-In Account provided the PAYIN.ACCOUNT has a limit attached to it.
PARTIAL: System debits the Pay-In Account only to the extent of funds
available.
NONE: If funds are not fully available to settle the bill, system would not debit
the Pay-In Account.

T3TAAD - R18 164
Settlement of Direct Debits 16
5
165
 Settlement Method for payment - option is DD
DD Transaction code must be mapped to AA activity through ACTIVITY.MAPPING

Product Condition
Payment rules for DD set in APPLY.PAYMENT field in PAYMENT.SCHEDULE Product

condition
 Payment Type
 Can hold any payment type defined in payment schedule
 DD.DDI record status should be AVAILABLE
When bills issued are to be settled directly by debiting an account in a third

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

T3TAAD - R18 165
Settlement – Receive funds – Transaction Recycler
166
 Transaction Recycler (RC) module captures transaction which cannot and should
not be completed - retries them until they are completed or abandoned.
 AA Bills made due online would be settled immediately.

Settlement processing would happen only if ‘Auto settle’ is enabled for the bill generated.
When the settlement account has enough funds to settle the bill it is settled immediately.
When there are no sufficient funds, an override is raised so that the user could decide if they
still want to go ahead with make-due even though Settlement would not happen.
When RC is configured in settlement product condition then the bill details would be
handover to RC.
 AA Bills Made Due during COB

 Settlement processing skipped – Bills handover to RC
Slide 166
From R13, Transaction Recycler (RC) module introduced captures transaction which cannot and should not be completed and retry them
until they are completed or abandoned.
Parameter tables can be used to define:
Choice of applications or products from which accounting entries which need to be captured and stored for recycling
Retry conditions for recycling rules like retry frequency, attempts and more.
Priority for transaction based on application, product and contract (by age and amount) when we have more than one transaction
outstanding against a settlement account
The transaction recycler service routines are triggered by linking it to the conditions for processing. Details of transactions to recycled are
stored in a live table with details of attempts and conditions and these files can be moved to history.
For transaction recycling in AA, the settlement product condition specifies the recycling condition and type to be used. During each retry
the recycler service draws the amount available in the settlement account for settling the transaction amount in full or partial based on the
configuration.
Transaction cycler would retry the failed transactions of a given settlement account during Close of Business through the job
RC.CYCLER.SERVICE, both during START.OF.DAY and END.OF.DAY stages. Every failed transaction would be retried both during
EOD and SOD stages and would count to one attempt.
If a transaction is handed over to RC but is settled outside of RC framework, then the transaction is not considered for further processing
by RC and is marked with a specific status.
AA Bills Made Due Online

Bills made due online would be settled immediately.
Settlement processing would happen only if ‘Auto settle’ is enabled for the bill generated.
When the settlement account has enough funds to settle the bill in full, then bill would be settled immediately.
When there are no sufficient funds, an override is raised so that the user could decide if they still want to go ahead with
make-due even though Settlement would not happen.
When RC is configured in settlement product condition then the bill details would be handover to RC.
AA Bills Made Due during COB
During COB when bills are made due AA settlement processing would be skipped and handover the bill details to RC ONLY if RC
configured in settlement product condition.
For COB transactions, when a transaction is handed over by the application to RC, it would be retried on the same date and at the same
stage.
For online transactions, if online settlement fails, then these would be picked for retry during that day’s EOD stage.
Subsequently, each failed transactions would be retried both during SOD and EOD stages of cycler job.
If a transaction is handed over to RC but is settled outside of RC framework, then the transaction is not considered for further processing
by RC.

T3TAAD - R18 166
Transaction Recycler – Retry Capture
167
RC.CAPTURE should be enabled for AA bills settlement hand off to AA

 Settlement Arrangement condition specifies recycling condition and frequency
RC.TYPE and RC.CONDITION specific for that Arrangement
On transaction recycling on the frequency date for a given settlement account, the
bills are prioritized based on :
• product group at company level
• product at product group level
• contracts under the product
The payment rule setup for the product should be kept in mind while prioritizing
the bills of an arrangement.
Possible to indicate combine bills facility and place a condition to settle only if all
bills of an arrangement are settled.
Slide 167
RC.CAPTURE is used to configure conditions/rules based on which a

transaction could be captured for recycling by the central Accounting
engine.
The record ID is EB.PRODUCT.ID and has to be enabled for any product ID
which needs Recycler.
This table contains the default RC condition with RC type for handoff from
other applications.
The record id is a valid EB.PRODUCT.ID and optionally could be followed by a
lead company code to define the recycling condition specific to that company.
In order to enable AA for Transaction Recycling, RC.CAPTURE should have a
record with Record id as AA
The Default RC condition and Default RC Type are mandatory fields of the
table RC.CAPTURE which can be populated with any preferred type and
condition record. Please note that handoff to RC from AA by Settlement product
condition contains the RC Type and RC Condition specific to that Arrangement
and only that type and condition would be used by Recycler.
The EB.SYSTEM.ID AAAA should be specified as the system id for which
Recycling has to be enabled.
The other fields like transaction code and suspense category to park the interim
entries are not applicable for AA.

T3TAAD - R18 167
Multiple Settlement Accounts 168
168
 Possible to specify multiple settlement accounts for payment of specific amount or

percentage - Possible to specify multiple Direct Debit instruction (DD.DDI) for
payment of specific amount or percentage
 Account Debit Rule given against each settlement account/DD.DDI will be

honoured
 Transaction Cycler not applicable for multiple accounts/DD.DDI settlements
 Associated set of Settlement account with Blank value in either the “Percent” or
“Amount” field this is considered as the default account.
Possible to specify multiple settlement accounts for payment of specific amount

or percentage - Possible to specify multiple Direct Debit instruction (DD.DDI)
for payment of specific amount or percentage. The Account Debit Rule given
against each settlement account/DD.DDI will be honoured. Transaction Cycler
not applicable for multiple accounts/DD.DDI settlements. In the associated set
of Settlement account with Blank value in either the “Percent” or “Amount”
field this is considered as the default account.
In the above example, a new deposit for £3,400.00 has been transacted. The
“Account Debit Rule” is defined as None. This feature enables the payment
being made by respective accounts of co owners.
Assume: 10995 has Account Balance £3,000.00 – 10944 has Account Balance
£5,000.00 – 11495 has Account Balance £550.00. Although 100% settlement has
been defined a setting of None has been defined, this means for each individual
account being defined the evaluation and rule setting of “None” will be
honoured. In the above case, only a total of £1,972 can be settled and this
amount will be taken from accounts 10995 and 10944, as account 11495 can’t
satisfy the portion of £1,428 i.e. 42% none will be taken from this account and
the remainder will be made due by the system.
The accounts will be debited as follows:
10995 : £1,122 leaving the balance as £1,878

T3TAAD - R18 168
10944 : £850 leaving the balance as £4,150.00
11495 : zero leaving the balance as £550.00

T3TAAD - R18 168
Settlement Instructions – Pay Out 169
169
 Meant for pay outs from an Arrangement
 Pay out examples:

 Pay-out of AA Deposit at maturity
 Scheduled Interest payment
 Could be to another T24 Account or T24 Arrangement
 Settle activity looks in settlement property based on the Property or Property Class,
fetches corresponding settlement instructions
 Pay-Out Settle Activity
 Activity run to pay funds, only APPLYPAYMENT allowed
 Can specify multiple pay out accounts defining either a percentage or fixed amount
The Settlement property class processes PAY bills either by specifying the
arrangement account reference / T24 Account in PAYOUT.ACCOUNT or by
creating DD.ITEM by providing DD.MANDATE.REF. In the settlement
property, user has to specify the Property class or property based on which bills
are to be settled by applying the PAYOUT.SETTLE.ACTIVITY. Settlement
property will function only if PAYOUT.SETTLEMENT is set to YES.
PAYOUT.PPTY.CLASS is the field that will enable the settlement of PAY
balance of any of the properties of that property class. Whereas, if the property
is specified in PAYOUT.PROPERTY, only the PAY balance relating to that
specific property will be settled. Back-dated adjustments will be handled only
when the settlement is from/to another T24 arrangement
From R17, multiple pay out account can be defined indicating a specific
percentage or a specific amount to paid out the account . This enables the
proceeds to be paid out the respective accounts of co owners.

T3TAAD - R18 169
Settlement Processing in different currencies 17
0
170
 Arrangement bills in one currency can be settled by:

 Another arrangement in same currency / another currency
 T24 Account in same currency / another currency
 Settlement processing is possible as follows:
Source Settlement Due bills

Arrangement Arrangement
LCY FCY -
FCY LCY -
FCY Same FCY -
FCY Different FCY -
Arrangement bills in one currency can be settled by another arrangement / T24

account with another currency. Settlement processing will happen when 1)
source arrangement is in local currency and settlement arrangement / account is
in foreign currency, 2) source arrangement in foreign currency and settlement
arrangement / account is in local currency, 3) both source arrangement and
settlement arrangement/account are in same foreign currency, 4) source
arrangement and settlement arrangement/account are in different foreign
currencies.

T3TAAD - R18 170
Offset Due and Pay Bills 17
1
171
 Possible to offset Pay bills generated with existing due bills and offset Due
bills generated with existing pay bills
 The property indicated would be offset with the pay or due bill
generated
 Offset Property Class/ Property – Indicates Property Class / Property balance
which needs to be offset.
 Offset Required - Defines whether offset of balances is required for the
property class / property.
 Active can be set as YES or NO
 Offset Pay in Activity - Specifies Offset Payment rule activity that defines the
list of due balances which need to be offset using the pay balance
 Offset Pay out Activity - Specifies Offset Pay-out rule activity which defines the
list of pay balances which need to be debited to offset due balance created
It is possible to offset Pay bills generated with existing due bills and offset Due
bills generated with existing pay bills. The property indicated would be offset
with the pay or due bill generated.
Offset Property Class - Property Class balance which needs to be offset.
Offset Property - Property balance that needs to be offset.
Offset Required - Defines whether offset of balances is required for the property
class / property.
Active Yes denotes offset required and No denotes offset not required.
Offset Pay in Activity Specifies the Offset Payment rule activity that defines the
list of due balances which need to be offset using the pay balance.
Offset Pay out Activity Specifies the Offset Pay-out rule activity which defines
the list of pay balances which need to be debited to offset due balance created.

T3TAAD - R18 171
Offset - Setup 17
2
172
 Possible to offset Outstanding Due bill raised against a Pay bill raised now
 Activity class < Product Line – Offset – Payment Rule Property Class>
 When a pay is raised, the due bill outstanding for the property indicated
will be settled immediately and remaining is paid
 Possible to offset outstanding Pay bill against Due bill raised now
 Activity class < Product Line – Offset – PayOut Property Class>
 When a due is raised, the pay bill outstanding for the property indicated
will be settled immediately and rest will be made due
It is possible to offset Outstanding Due bill raised

against a Pay bill raised now. The Activity class < Product Line
– Offset – Payment Rule Property Class> is used for the same. When a pay is
raised, the due bill outstanding for the property indicated will be settled
immediately and remaining is paid
It is possible to offset outstanding Pay bill against Due bill raised now. The
Activity class < Product Line – Offset – PayOut Property Class> is used for the
same. When a due is raised, the pay bill outstanding for the property indicated
will be settled immediately and rest will be made due

T3TAAD - R18 172
OFFSET – Features and Limitations 17
3
173
 Settlement instructions for payin and payout are triggered after offset
 Excess funds after settlement will be available as Due or Pay amount

 UNC settlement is also triggered after Offset is completed
 For DD claims, Claim amount received is settled through UNC which
would be triggered after Offset is completed
 Amount pending after offset would be split between multiple
settlement accounts if setup
 Order of bill property updated in arrangement to settle when two bills
are made due at the same point
 Periodic charges for offset under settlement setup is not supported
 From Accounting perspective, instead of settling a due and pay bill
separately, the net amount is settled – Hence there would be no
separate impact in position
Settlement instructions for payin and payout like DD item or UNC settlement or
multiple accounts setup or RC are triggered after offset settlement instructions
are executed.
Excess fund pending to be settled (either PAY or DUE) after the offset, follows
the regular settlement procedure and remains as PAY bill or DUE bill.
UNC settlement can be achieved using <PRODUCT.LINE>-SETTLE-

<PAYMENT.RULE> in APPLYPAYMENT field of PAYMENT.SCHEDULE to
Repay from Credit balance. When offset is also setup for the same settlement,
the offset settlement is completed (to settle the due against pay or pay against
due) and the remaining amount is settled from UNC.
For Direct Debits, the claims are raised in advance during ISSUEBILL activity
for the actual bill amount and funds are credited in UNC. If offset is also
configured in this setup, offset is completed and the remaining funds are settled
from UNC.
When Multiple Settlement accounts are setup, the remaining bill amount after
offset would be divided between the settlement account as per the percentage
setup. For amount option, the amount indicated against each account would be

T3TAAD - R18 173
amount debited as required by the outstanding bill. Once the bills are settled further
debit to the next account might be stopped.
When there are two bills raised on the same time, the order of priority for settlement is
from bill property order updated in payment rules setup.
Offset settlement is not applicable for Periodic Charge bills.
Let's assume a pay bill of £100 is offsetting an outstanding due bill of £30. If offsetting
is not done there will an ft or settlement entries raised for -30 and + 100 separately, with
offsetting 70 £ would be settled. Effective settlement amount does not change – So
Offsetting would not have separate impact on Positions.

T3TAAD - R18 173
Settlement to a Beneficiary 17
4
174
 Payment order can be generated for disbursement or repayment of Loan

arrangements
 PAYIN.BENEFICIARY and PAYIN.PO.PRODUCT, PAYOUT.BENEFICIARY and

PAYOUT.PO.PRODUCT indicates the Beneficiary information and the relevant
payment order product for configuration
 <Pl>-ISSUE.ORDER-ARRANGEMENT activity class indicates payment order

generation
 Pay Out orders requests will update the new suspense balance ADVANCE and
ADVSUSPENSE – no new Balance types for Payment
 “Issue Payment Order” to create the order request
 “Accounting” only for Payout - “ADVANCE” balance type and the new
suspense balance accounting entry
Payment order can be generated for disbursement or repayment of Loan

arrangements. PAYIN.BENEFICIARY and PAYIN.PO.PRODUCT,
PAYOUT.BENEFICIARY and PAYOUT.PO.PRODUCT indicates the
Beneficiary information and the relevant payment order product for
configuration. <Pl>-ISSUE.ORDER-ARRANGEMENT activity class indicates
payment order generation. Pay Out orders requests will update the new suspense
balance ADVANCE and ADVSUSPENSE – no new Balance types for Payment .
“Issue Payment Order” action is to create the order request in both payment and
pay out using Beneficiary. “Accounting” action is used only for Payout -
“ADVANCE” balance type and the new suspense balance accounting entry

T3TAAD - R18 174
Payment Orders in Advance 17
5
175
 Possible to generate Payment order in advance for both pay and due bills
 ORDER.DELIVERY in Payment Order Product
 DAYS.DELIVERY in Currency
 Considers the holiday calendar and moves payment order generation date based
on Account Property Class
 Any changes in bill amount would not result in automatic correction of payment
order
Payment order can be generated in advance for the pay and due bills.
ORDER.DELIVERY in Payment Order Product and DAYS.DELIVERY in
Currency can be used to indicate the number of advance days. If we have
advance dates in both the tables, the advance date would be a sum of both the
values. This is correlated with holiday calendar and incase of holiday, the
payment order date is moved according to the Account Property Class setup.
Note that, Once the order has been generated any amendment to the contract that
effects the payment amount will not regenerate the difference or amended the
payment orders generated. Any required correction to the payment will need to
be a manual process. However, a suitable Override message is produced warning
the user of this case.

T3TAAD - R18 175
Arrangement - Settlement to a Beneficiary 17
6
176
The deposit arrangement is updated with payment order instruction.

The arrangement has settlement instructions to settle internally but through
Payment orders.

T3TAAD - R18 176
Bill – Payment Order 17
7
177
The payment order is placed and handed over to tps for further process.

T3TAAD - R18 177
Workshop –SETTLEMENT Product Condition 17
8
178
 Use Admin Menu > Product Builder > Product Conditions > SETTLEMENT
For receiving deposit funds:

Payment type is DEPOSIT.PRINCIPAL
Settle activity is to be defined as DEPOSITS-APPLYPAYMENT-PR.DEPOSIT
Recycler setup should done for repeating indefinitely
Settlement instructions should be active
Pay-In account should be debited only to the extent of funds available
For paying out Interest / Charge / Principal:

Define settle activity as DEPOSITS-APPLYPAYMENT-PO.DEPOSIT
Settlement instructions should be active
 All attributes are negotiable by default.
Create a Settlement Product condition.

T3TAAD - R18 178
9
179
In this workshop, we will see how to create a Settlement Product condition.

For receiving deposit funds:
Payment type is DEPOSIT.PRINCIPAL ,
Settle activity is to be defined as DEPOSITS-APPLYPAYMENT-
PR.DEPOSITS,
Recycler setup should done for repeating indefinitely
Settlement instructions should be active,
Pay-In account should be debited only to the extent of funds available,
For paying out Interest / Charge (Bonus)/ Principal:
Define settle activity as DEPOSITS-APPLYPAYMENT-PO.DEPOSIT,
Settlement instructions should be active,
All attributes are negotiable by default.

T3TAAD - R18 179
Payment Rules Property Class 18
0
180
Payment
Customer
Schedule
Account Closure
Deposits
Activity
Officers
Restriction
Tax Accounting

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

This defines how a single payment amount due to be paid by customer to a Bank,
is to be handled.
This Class does not depend upon currency and multiple Properties of this class
can be attached to a Product.

T3TAAD - R18 180
Payout Rules Property Class 18
1
181
Payment
Customer
Schedule
Account Closure
Deposits
Activity
Officers
Restriction
Tax Accounting
Activity Activity Activity

Payout Rules
Presentation Mapping Charges
PAYOUT.RULES is a mandatory Property Class of DEPOSITS Product Line.

This defines how a single payment amount due to be paid to a customer is to be
handled.
This Class does not depend upon currency and multiple Properties of this class
can be attached to a Product.

T3TAAD - R18 181
Payment Rules & Payout Rules – Property Classes 18
2
182
 Both define Rules for handling a payment

 Payment rules – Used when Customer pays to Bank
 Payout rules – Used when Bank pays to Customer
 Property Type is product only
 Product condition is Dated, Multiple and Tracking

Property
Class
PAYMENT
RULES
Attributes
Types
DATED, MULTIPLE, Property
TRACKING Class
PAYOUT
RULES
Each Deposits T24 product will mandatorily have a PAYOUT.RULES and a

PAYMENT.RULES Property defined.
A deposit arrangement may have one or more bills outstanding, due to be paid to
the customer. For this, Payout rules property is used to define how the payment
is to be handled.
When there are one or more bills outstanding pertaining to charges payable by a
Customer, Payment rules property is defined as to how the payment is to be
handled.
Whether the first bill is to be settled first or the last bill is to be settled first, the
sequence in which the properties should be settled is also defined in these
properties.

T3TAAD - R18 182
Payout Rules & Payment Rules – Product Condition 18
3
183
 Payment application type

 Specifies how the payout / payment rules will apply to an arrangement
 Payments application order

 Oldest first – earliest one followed by later bills one after the other
 Oldest last – the latest one first and then the previous one, so on
 Property sequence
 Specifies the property sequence in which balances will be affected during repayment
 Must be a valid property of Interest, Charge or Principal amount
APPLICATION.TYPE Field - used to specify how the payment rules / payout

rules will apply to an arrangement.
APPLICATION.ORDER Field - For billed amounts, in addition to specifying
which Properties will be given priority, the user must decide in which order
multiple bills will be processed. This field can be used to specify the order in
which multiple bills has to be processed.
Options are:
1. Oldest First - Order of processing will start from first bill.
2. Oldest Last - Order of processing will start from last bill.
PROPERTY.SEQUENCE - Specifies the property sequence in which balances
will be affected during repayment

T3TAAD - R18 183
Payout Rules Definition 18
4
184
 Funds in PAY / UNC / CUR balances can be withdrawn
 Payment application type can hold values: CURRENT.PAY, PAY and

DEPOSIT.RULE.PAY
Field Withdrawal from Withdrawal Total withdrawal from

CUR balance from UNC PAY balance
balance
PROP.APPL.TYPE CURRENT BLANK BLANK
APPLICATION.TYPE CURRENT.PAY PAY DEPOSIT.RULE.PAY
Funds lying in either of the PAY Balances, UNC balances or CUR balances can
be withdrawn with suitably defined payout rules. Payment application type field
can hold the values of CURRENT.PAY, PAY and DEPOSIT.RULE.PAY.
If withdrawal from a principal balance is required, then a payout activity with
the value CURRENT in PROP.APPL.TYPE must be used along with the
APPLICATION.TYPE set as CURRENT.PAY.
If withdrawal is to be made from UNC balance, then a payout activity with the
value BLANK in PROP.APPL.TYPE must be used along with
APPLICATION.TYPE set as PAY.
If complete redemption of deposit is required, then a payout activity with the
value BLANK in PROP.APPL.TYPE must be used along with
APPLICATION.TYPE set as DEPOSIT.RULE.PAY.

T3TAAD - R18 184
Deposit Redemption - other features 18
5
185
 Pre-closure of deposit possible with withdrawal of all available balances
 Simulation of a redemption / partial withdrawal from deposit arrangement is possible
 Simulation can be on a current date / future date / back date
Withdrawals / partial withdrawals in a given period of time can be controlled through
ACTIVITY.RESTRICTION and PERIODIC.RULES
 Charges can be attached to the above

 Charges can be made due / deferred
 Can be collected for all transactions / select transactions
 Charge API routine for early redemption / withdrawal penalty
Pre-closure of contracts is permissible by virtue of withdrawal of all available

balances including accrued interest.
Simulation of a withdrawal transaction is possible on the current date, on a
future date or a back dated date. Pre-closure of contracts is permissible by virtue
of a withdrawal of all available balances including accrued interest.
User has the option of controlling the withdrawals from an arrangement in a
given period of time, by using ACTIVITY.RESTRICTION and
PERIODIC.RULES
The user also can choose to charge the customer for withdrawals more than the
permissible ones. The user has the option to charge the customer for every
transaction performed on this contract or selected transactions only. The charges
can also be deferred over a certain period of time, depending upon the
customer’s requirement. The user also can capture balances for takeover
contracts and do withdrawals for the same.
Early redemption charges / penalties for deposits vary greatly from institution to
institution. To cater to this requirement, an API (charge routines) can be defined
as per the Bank’s needs and then specified in the CHARGE Property condition.
This can be applied to ACTIVITY.RESTRICTION or ACTIVITY.CHARGE
Properties as required.

T3TAAD - R18 185
Workshop – PAYMENT RULES Setting 18
6
186
 Use Admin Menu > Product Builder > Product Conditions > PAYMENT.RULES
Choose Application Type as BILL.DATE
Earliest bills to be paid first
Pay off Bills in the following order:
 Properties :
 DEPOSITCHARGE
 DEPADMINFEE
Reminder activity DEPOSITS-CREDIT-ARRANGEMENT

Make due bill set as no.
All Attributes are negotiable by default
Create a Payment Rules Product condition.

T3TAAD - R18 186
187
In this workshop, we will see how to create a Payment Rules Product condition.
Choose Application Type as BILL.DATE,
Earliest bills to be paid first
Pay off Bills in the following order:
Properties : DEPOSITCHARGE
DEPADMINFEE
Reminder activity DEPOSITS-CREDIT-ARRANGEMENT
Make due bill set as no.

T3TAAD - R18 187
Workshop – PAYOUT RULES Setting 18
8
188
 Use Admin Menu > Product Builder > Product Conditions > PAYOUT.RULES
Choose Application Type as DEPOSIT.RULE.PAYOUT
Earliest bills to be paid first
Pay off Bills by Property in the following order:
 Properties : ACCOUNT, DEPOSITINT
Create a Payout Rules Product condition.

T3TAAD - R18 188
9
189
In this workshop, we will see how to create a Payout Rules Product condition.
Choose Application Type as DEPOSIT.RULE.PAYOUT,
Earliest bills to be paid first,
Pay off Bills in the following order:
Properties : ACCOUNT, DEPOSITINT,

T3TAAD - R18 189
Activity Mapping Property Class 19
0
190
Payment
Customer
Schedule
Account Closure
Deposits
Activity
Officers
Restriction
Tax Accounting

ACTIVTY.MAPPING is a mandatory Property Class of DEPOSITS Product

Line. This Property is used to map the T24 Transaction Codes to various Deposit
Activities, such that other T24 Applications like FT, Teller, etc. can be used to
trigger Activities related to an Arrangement like funding, payment, etc.

T3TAAD - R18 190
Activity Mapping - Property Class 19
1
191
 Only one property can be attached to Product Group
 Values cannot be viewed or edited at arrangement level
 Arrangement level values track changes to Product condition
Property Class
ACTIVITY.MAPPING
Attributes
Type
DATED,
MERGE,
TRACKING.ONLY
Only one Property of ACTIVITY.MAPPING can be attached to a Product

Group.
Since its Type is set to TRACKING.ONLY, the Arrangement level values will
always track changes to the Product Condition. Further, its values cannot be
viewed or edited at the Arrangement level.

T3TAAD - R18 191
Activity Mapping - Product Condition 19
2
192
 Transaction
Deposit Payments and withdrawals in arrangements initiated through Account based
applications like FT, TELLER
Transactions triggered through Transaction Codes
Transaction Codes of other applications that trigger AA activities specified
 Transaction Activity
Activity performed in an arrangement when a movement with associated Transaction
Codes is posted from FT, Teller etc
 Default Activities for unmapped Transaction Codes of Debits and Credits can be
specified
TRANSACTION Field in ACTIVITY.MAPPING product condition is used to

specify the Transaction code of External application to trigger a specified AA
Activity set in the ACTIVITY Field.
Besides specified Codes mapped to trigger specific AA activity, AA Activities to
be triggered by default for unmapped transaction codes are set for Debit and
Credit Separately.
TXN.ACTIVITY Field is used to specify the activity that will be performed
against an arrangement when a movement with the associated TRANSACTION
code is posted from an external application to an Arrangement Account. This
field is part of a multi value set with TRANSACTION Field.

T3TAAD - R18 192
Activity Mapping – Links 19
3
193
 Transaction Type
ACDF
 Maps to Transaction Code
FT.TXN.TYPE.CONDITION
 Using FT.TXN.TYPE.CONDITION
483
 Which maps to Activity

Activity Mapping
 Using AA Activity Mapping
DEPOSITS- APPLYPAYMENT-
DEPOSIT.PAYMENT.RULE
 Similar mappings for

 AC.CASH.POOL (AC.SWEEP.TYPE) and TELLER (TELLER.TRANSACTION)
Let us take an example of using FT to fund an Arrangement. FT transactions are

controlled by its parameter table FT.TXN.TYPE.CONDITION. Here a record
ACDF has been defined for the AA Deposit funding and a transaction code of
483 is linked to it for credit.
In the ACTIVITY.MAPPING Product Condition linked to a Deposit Product,
the Transaction Code 483 has been mapped to the Activity DEPOSITS-
APPLYPAYMENT-DEPOSIT.PAYMENT.RULE. This Activity has been derived
from the Activity Class: DEPOSITS-APPLYPAYMENT-PAYMENT.RULE.
You can see that the FT to Fund the Arrangement has been input with the
Transaction Type: ACDF and thus uses the Transaction Code 483 for credit
processing. Thus, the DEPOSITS-APPLYPAYMENT-
DEPOSIT.PAYMENT.RULE Activity has been triggered.
The process works exactly the same in AC.CASH.POOL and TELLER.

T3TAAD - R18 193
Demo – Activity Mapping Product Condition 19
4
194
We can see the Activity Mapping Product condition set as

Transaction Code 483 to DEPOSITS-APPLYPAYMENT-
DEPOSIT.PAYMENT.RULE activity
Transaction Code 486 to DEPOSITS-APPLYPAYMENT-
DEPOSIT.PAYOUT activity
DEPOSITS-CREDIT-ARRANGEMENT activity to Default
Credit
DEPOSITS-DEBIT-ARRANGEMENT activity to Default Debit
DEFAULT.NEGOTIABLE to NO

T3TAAD - R18 194
Activity Mapping – Event Mapping 19
5
195
 Possible to link between External Applications and AA for non financial

transactions as well under Activity Mapping
 TEC.ITEMS are linked to Activities in AA and defines which service it

belongs to
Specifies the Event from service name from the

Activity under the Record virtual table
TEC.ITEMS – Events with Item
Classification ‘AA Event Arrangement Activity AA.SERVICE
Class – triggered for the
Service”
corresponding Event
From R17, it is possible to map Tec items to AA activities. These activities can
be grouped to different services offered.
Activity mapping property class provides a link between external (non-AA)

applications and Arrangement activities including non financial transactions.
Activity Mapping indicates the Activity is to be triggered when a non-financial
transaction is done on an arrangement account through a non-AA / external
application. Also, defines which service an activity belongs to.
EVENT Specifies the event for which the activity mapping is defined. The
TEC.ITEMS that have the ITEM.CLASSIFICATION as ‘AA Service’ can be
given here.
EVENT.ACTIVITY Indicates the activity (of activity class <Product Line>-
RECORD.EVENT-ARRANGEMENT) which has to be triggered for the
corresponding event.
EVENT.SERVICE - gives service name to which the activity and event belongs
to from virtual table AA.SERVICE.
Whenever an activity is triggered with a service associated to it, the service

T3TAAD - R18 195
information will be passed to activity restriction for validation. This will be done for
both financial and non-financial activities. Discussed in detail further in Facility
property class

T3TAAD - R18 195
Quiz – Choose the correct Answers 196
196
Quiz 1. What cannot be defined in Payment Schedule Product Condition ?
a) Properties to be included in the Schedule
b) Payment Frequency
c) Combining bills falling due on different dates
d) Payment Frequency as well as Due Frequency

T3TAAD - R18 196
Quiz – True or False 19
7
197
Quiz 1. Activity Mapping Property provides the link between external

applications and arrangement activities when performing debit or
credit to an arrangement account
True
a)
False
b)

T3TAAD - R18 197
8
198
Conclusion  We have now learn about parameters for Bill

Generation and Payments
 Payment Schedule Property Class
 Settlement Property Class
 Payment Rules Property Class
 Payout Rules Property Class
 Activity Mapping Property Class

T3TAAD - R18 198
19 19
9 9
199
Advanced Parameters

T3TAAD - R18 199
0
200

advanced parameters for performing
activities in arrangements
 Constraint Property Class
 Periodic Attributes in Property Classes
 Activity Restriction Property Class

T3TAAD - R18 200
Constraint Property Class
201
Payment
Customer
Schedule
Account Closure
Lending
Activity
Officers
Restriction
Overdue Accounting
Activity Activity Periodic

Constraint Mapping Charges Charges
Slide 201
Constraint property class allows defining of conditions on how far a back dated
activity can be performed.
Whenever a back dated activity is performed, system would check the restriction
period defined and trigger an error or override when restriction is breached.

T3TAAD - R18 201
Constraint - Property Class
202
 Constraint Property class is optional
 Constraint Property can be set as Tracking and it is Dated
Type Property Class

CONSTRAINT
DATED, TRACKING
Balance
Prefix
Slide 202
Constraint Property class is used to define the constraints on the arrangement.

Constraint Property class is optional
Constraint Property can be set as Tracking and it is Dated

T3TAAD - R18 202
Constraint – Product Condition
203
 Possible to restrict the backdating of events prior to current billing period and
current billing period as well
 An override or error can be triggered when the restriction is breached
 Type of constraint can be

 Any activity prior to past interest period (billing Period) is restricted
 Activity prior to last Account statement generation date is restricted
 Specific Period prior which backing dating is restricted
 A Specific Date prior which backing dating is restricted
 Any activity prior to Renewal Date to be restricted
Slide 203
This functionality provides flexibility to the bank in restricting the backdating of

events prior to current billing period and current billing period as well.
An override or error can be triggered when the restriction is breached
Type of constraint can be on:

• INTEREST.PERIOD – Activity would be restricted and governed by
the Interest period of the arrangement. For example, to block any
activity past the billing period, this option may be used.
• STATEMENT.PERIOD – Constraint would be based on when the
statement was last generated for this account. When multiple
statements are generated(including special ones), the latest
statement date of them all would be taken and any date prior to that
would be restricted.
• RENEWAL – When this option is chosen, any activity prior to the last
renewal date would be restricted
• PERIOD – User could state a specific period(say 1M, 6M etc) to
indicate specific periods before which the activity would be restricted
• DATE – Indicates a hard date prior to which back dating would be
restricted

T3TAAD - R18 203
This is a Non Mandatory field.

T3TAAD - R18 203
Constraint – Product Condition
204
Detail – gives the interest property to be considered for restricted in billing

period type of restriction
Period – gives the actual period for restriction in case of specific Period,
specific date, interest period.
 RESULT – outcome of a constraint can result in error or override
ERROR. MESSAGE, OVERRIDE. MESSAGE defines the desired error message or

override message to be displayed when constraint is breached.
Slide 204
DETAIL - Indicates further details to support the field stated in TYPE stated in
the previous field.
If INTEREST.PERIOD is stated in the TYPE field, the name of the Interest
property whose interest that needs to be considered for billing consideration
needs to be stated here.
Mandatory when TYPE is INTEREST.PERIOD else NO input
PERIOD
Period or date allowed based on the TYPE stated. Indicate the actual period of
constraint - Valid Numerical value
options are:
If TYPE is INTEREST.PERIOD - Allows a numeric value in this field (for
example, no backdating prior to 3 interest periods). If nothing is stated, system
would not allow any backdating prior to current interest period by default
If TYPE is PERIOD – A valid IN2PERIOD value should be stated in this field.
The field is mandatory with this option.
If TYPE is stated as DATE – A Valid date value should be stated in this field.
The field is mandatory with this option.
If TYPE is stated as STATEMENT.PERIOD, RENEWAL - no input field

T3TAAD - R18 204
Allowed only if TYPE field is defined – Else No input
RESULT
This field indicates the outcome of the constraint.
The field is mandatory when TYPE field is chosen. Otherwise, could be left blank.
ERROR – Any violation of constraint would result in Error and would stop the activity.
OVERRIDE – Any violation of constraint would result in Override and would require
approval to proceed with the activity. The override could be converted to an error if need
be in OVERRIDE application.
ERROR.MESSAGE
If the option chosen is ERROR on RESULT field, a user defined EB.ERROR may be
stated here. This is only to differentiate one error from other when different options are
chosen. If no message is stated, a default generic error message would be used.
Optional field. If no message is stated, system would use the default error message - AA-
CONSTRAINT.VIOLATED. Should be a valid entry in EB.ERROR
OVERRIDE.MESSAGE
If the option chosen is OVERRIDE on RESULT field, a user defined OVERRIDE
message may be stated here. This is only to differentiate one override from other when
different options are chosen. If no message is stated, a default generic override message
would be used.
Optional field. If no message is stated, system would use the default override message -
AA-CONSTRAINT.VIOLATED. Should be a valid entry in OVERRIDE application

T3TAAD - R18 204
Advanced Concepts 20
5
205
Periodic Rules

T3TAAD - R18 205
AA.PERIODIC.ATTRIBUTE.CLASS 20
6
206
 Certain periodic attribute classes are predefined by Temenos Property

Class
AA.PROPERTY.CLASS whose condition uses
Action
the periodic rule Periodic
Comparison Attribute
ACTIVITY.RESTRICTION, ACCOUNT, Class
CHARGE, INTEREST and TERM.AMOUNT Type
ACTION for AA.PROPERTY.CLASS Data Type

Routine
RECEIVE, REDEEM, INCREASE,
DECREASE ……
Comparison Types for rules defined in

EB.COMPARISON.TYPE Table
MINIMUM, MAXIMUM, +BASISPOINTS, .........
Data types allowed to use Periodic Rule ROUTINE that returns value for
are hard coded comparison routine to do comparison
from Property record. Valid entry in
AMT, PERIOD, A, D, N, R, DAO EB.API File
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.

T3TAAD - R18 206
AA.PERIODIC.ATTRIBUTE.CLASS – User Defined 20
7
207
 Users are allowed to create their own periodic attribute classes by selecting the
following:
Property Class whose condition uses the periodic rule
Action to be performed on the property class. It is a multi value field
Multiple comparison types - MINIMUM, MAXIMUM, etc
Data Types – AMT, RATE, etc
Value Routine - Should be valid entry in EB.API file. If no routine is input, system triggers an
error
Type – Cap, Floor, Balance Type
 System Generated
This field is left blank for a user defined periodic attribute class
‘Yes’ displayed if the periodic attribute class is released by Temenos
Previously Temenos released the periodic attribute classes. From R13, users can
create their own periodic attribute classes. The COMPARISON.TYPE field in
AA.PERIODIC.ATTRIBUTE.CLASS is multi-valued to hold the "possible"
types that can be used for the periodic attribute. It enables Users to select
different comparison types from the EB.COMPARISON.TYPE table. Once
created, the user cannot delete this field. The data type based on which the
periodic attribute should be validated should be selected. For example: AMT =
AMOUNT, R = RATE . The routine to be used for the comparison types of the
property class should be valid entry in EB.API file. This routine is mostly used
for local development. This is a mandatory field.
‘Type’ - This is a multi-value field which is used to define the type of rule if
broken. The values allowed in this field are Cap, Floor and Balance Type.
The ‘System Generated’ field is left blank for a user defined periodic attribute
class and displayed as ‘Yes’ for a temenos released periodic attribute class. This
can be viewed only through command line

T3TAAD - R18 207
AA.PERIODIC.ATTRIBUTE 20
8
208
 Periodic Attribute is a named type / instance of a Periodic Attribute Class

 Periodic Attribute is used in Product Condition
Rule that needs to be applied on a specific PR.ATTR.

period or life time of Arrangement. Is
CLASS
controlled by PERIOD.TYPE Field
PERIOD.
LIFE, INITIAL, REPEATING & ROLLING
TYPE
Periodic
Attribute
PERIOD field controls exact period for which PERIOD

Rule is defined
01D, 5M, 2Y,…
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 )

T3TAAD - R18 208
AA.PERIODIC.ATTRIBUTE 20
9
209
 Periodic Attribute is a named type / instance of a Periodic Attribute Class

 Periodic Attribute is used in Product Condition
Rule that needs to be applied on a specific PR.ATTR.

period or life time of Arrangement. Is PERIOD.
TYPE CLASS
controlled by PERIOD.TYPE Field
LIFE, INITIAL, REPEATING & ROLLING
PERIOD field controls exact period for which Periodic

Rule is defined PERIOD Attribute
01D, 5M, 2Y,…
RULE.START Field represents Base Date

ERROR /
AGREEMENT, ANNIVERSARY, RULE.START OVERRIDE
ARRANGEMENT, COOLING-OFF & START MESSAGE
RULE.ERR.MSG and RULE.OVE.MSG Fields

control generation of ERROR and OVERRIDE
messages respectively
RULE.START Field represents start date of the period defined. Possible values
are:
AGREEMENT – Effective start Date of the Product; ARRANGEMENT– start
date of deposit Arrangement;
START – takes the first date of funding deposit as the base date; if not funded,
then the arrangement start date will be taken till it is funded;
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 deposit 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 withdrawal or pre-

T3TAAD - R18 209
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.

T3TAAD - R18 209
AA.PERIODIC.ATTRIBUTE – User Defined 21
0
210
 Periodic Attribute is a named type / instance of a Periodic Attribute Class
 Periodic Attribute is used in Product Condition
Rule that needs to be applied on a specific PERIOD. TYPE

period or life time of Arrangement. Is
controlled by PERIOD.TYPE Field PR.ATTR.
LIFE, INITIAL, REPEATING & ROLLING PERIOD CLASS
PERIOD field controls exact period for which

Rule is defined
RULE.START Periodic
01D, 5M, 2Y,…
Attribute
RULE.START Field represents Base Date COMPARISON
AGREEMENT, ANNIVERSARY, .TYPE
ARRANGEMENT, COOLING-OFF & START ERROR /
OVERRIDE
TYPE
MESSAGE
COMPARISON.TYPE to be selected from
predefined comparison types in periodic
attribute class
RULE.ERR.MSG and
RULE.OVE.MSG Fields control
Type should be a valid type defined in generation of ERROR and OVERRIDE
periodic attribute class messages
Users can create their own periodic attributes. The comparison types should be
selected from the predefined comparison types selected when creating the user
defined periodic attribute class. Once the comparison type is selected, it cannot
be deleted. The type (Balance type, cap, floor) selected should be the same as
defined in periodic attribute class, else an error is triggered.

T3TAAD - R18 210
Periodic Rules - Structure 211
211
Periodic Attribute Class
Property Class Comparison Type Routine
Periodic Attribute
Time Element
Periodic Rule in the Product Condition for the Property Class

Periodic Comparison
Break Result Break Charges
Attribute value
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.

T3TAAD - R18 211
Periodic Attribute Class - Interest Property Class 21
2
212
MAXIMUM RATE - Periodic Rule for Maximum Interest Rate
MINIMUM RATE - Periodic Rule for Minimum Interest Rate
RATE DECREASE - Periodic Rule for Rate Decrease
RATE DECREASE TOLERANCE - Periodic Rule for Rate Decrease in percentage
RATE INCREASE - Periodic Rule for Rate Increase
RATE INCREASE TOLERANCE - Periodic Rule for Rate Increase in percentage
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.INCREASE.TOLERANCE - Checking the percentage increase in rate of
interest

T3TAAD - R18 212
Periodic Attribute Class -Term amount & Account Property Class 21
3
213
Term Amount
AMOUNT DECREASE - Periodic Rule to control decrease in Principal Amount
AMOUNT DECREASE TOLERANCE - Periodic Rule to control percentage decrease in Principal

Amount
AMOUNT INCREASE - Periodic Rule to control increase in Principal Amount
AMOUNT INCREASE TOLERANCE - Periodic Rule to control percentage increase in Principal

Amount
Account
FULL.DEPOSIT – Periodic rule to control the deposit of full commitment amount
Term Amount Property Class:

AMOUNT DECREASE - Periodic Rule to control decrease in Principal
Amount.
AMOUNT DECREASE TOLERANCE - Periodic Rule to control percentage
decrease in Principal Amount.
AMOUNT INCREASE - Periodic Rule to control increase in Principal Amount.
AMOUNT INCREASE TOLERANCE - Periodic Rule to control percentage
increase in Principal Amount.
Account Property Class:
FULL.DEPOSIT – Periodic rule to control the deposit of full commitment
amount.

T3TAAD - R18 213
Periodic Attribute Class - Activity Restriction Property Class 21
4
214
 TRANSACTION AMOUNT MAXIMUM - Periodic Rule to control Maximum Transaction Amount
 TRANSACTION AMOUNT MINIMUM - Periodic Rule to control Minimum Transaction Amount
 TRANSACTION AMOUNT MULTIPLE - Periodic Rule to control Transaction Amount in Multiples,

E.g. deposit amounts in 100s
 TRANSACTION AMOUNT TOTAL - Periodic Rule to control Total Transaction Amount, E.g. total
deposit amount not less than 100,000
 TRANSACTION COUNT TOTAL - Periodic Rule control Total Number of Transactions, E.g. not more
than 2 partial withdrawals in a year
 FULL.REDEEM - Periodic Rule to control Redemption of Deposit
TRANSACTION AMOUNT MAXIMUM - Periodic Rule to control Maximum

Transaction Amount.
TRANSACTION AMOUNT MINIMUM - Periodic Rule to control Minimum
Transaction Amount.
TRANSACTION AMOUNT MULTIPLE - Periodic Rule to control Transaction
Amount in Multiples, E.g. deposit amounts in 100s.
TRANSACTION AMOUNT TOTAL - Periodic Rule to control Total
Transaction Amount, E.g. total deposit amount not less than 100,000 .
TRANSACTION COUNT TOTAL - Periodic Rule control Total Number of
Transactions, E.g. not more than 2 partial withdrawals in a year.
FULL.REDEEM - Periodic Rule to control Redemption of Deposit.

T3TAAD - R18 214
Workshop - 21
5
215
 Use MB Admin Menu > Product Builder > Additional Settings > Periodic
Attributes > TERM.AMOUNT Property Class
 Set a periodic attribute for decreasing Principal amount during the life of the
arrangement
Set a Periodic Attribute for decreasing Principal amount during the first year of
the arrangement. This is to be attached to your existing Term Amount product
condition.

T3TAAD - R18 215
6
216
Set a Periodic Attribute under Term Amount Property Class for restriction in
decreasing Principal amount.
In the periodic attribute set the following:
Rule to be applied for life of the arrangement,
With effect from start date of arrangement

T3TAAD - R18 216
Activity Restriction Property Class 21
7
217
Payment
Customer
Schedule
Account Closure
Deposits
Activity
Officers
Restriction
Tax Accounting

ACTIVITY.RESTRICTION is an optional Property Class of DEPOSITS

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.

T3TAAD - R18 217
Activity Restriction – Property Class 21
8
218
 This Property Class allows Multiple Properties and is TRACKING type
 Currency and Date Specific
 Product Condition to be created for every currency
Property Class
for
Attributes Types ACTIVITY
DATED, CCY, MULTIPLE, RESTRICTION
TRACKING,
FORWARD.DATED
ACTIVITY.RESTRICTION Property class is DATED, CCY, TRACKING,

MULTIPLE and FORWARD.DATED.
During an activity, if permitted, user can amend or delete any of the future
conditions.

T3TAAD - R18 218
Activity Restriction – Product Condition 21
9
219
 Full restriction of Activity

Activity cannot be run altogether
 e.g. Not to allow change of Term of Arrangement
Error message is Mandatory
 Activities can be refined into a partial or conditional restriction
Control activity but allow with override
 e.g. Allow more than 5 deposit repayments in a year only after approving override,
deposit receipts must be in multiples of 100
Override message is Mandatory
It can be controlled by Periodic Rules
 For Transactions this can be refined into a partial or conditional restriction
 Deposit receipts must be in multiples of 100
 It can be controlled by Periodic Rules
ACTIVITY.Id is the activity on which transaction rules need to be applied. Any

valid AA.ACTIVITY may be stated here.
RESTRICT Field allows for the complete restriction of the specified activities.
The user can flag this field to indicate that the activity is to be restricted and can
further specify whether the transaction is completely blocked or allowed with a
warning. Accept YES or NO; If YES then RESTRICT.TYPE is mandatory.
RESTRICT.TYPE Field is used to set restriction that need to be applied on the
activity. ERROR - The transaction triggering this activity would be completely
blocked. OVERRIDE - The transaction triggering this activity would be allowed
after displaying a warning. If OVERRIDE is specified then RESTRICT.OVR is
mandatory. RESTRICT.ERROR - If transaction is completely blocked, you can
state a error message displaying restriction. Should be a valid entry in
EB.ERROR table.
If ERROR is specified then RESTRICT.ERROR is mandatory. RESTRICT.OVR
: If the transaction is to be allowed after displaying a warning, then the user can
state a override message here which would appear whenever this activity is
triggered on an arrangement. Should be a valid entry in OVERRIDE table.
You can prevent an Activity from occurring. Do not allow Activity DEPOSITS-
CHANGE.TERM -COMMITMENT. User can also allow activities with some
restrictions, like not more than 5 repayments in a year; Receipts in multiples of
100 etc. This is achieved by linking periodic rules to the

T3TAAD - R18 219
ACTIVITY.RESTRICITON Product Conditions. We will see more of Periodic rules,
later.

T3TAAD - R18 219
0
220
 Use Admin Menu > Product Builder > Additional Settings > Periodic
Attributes > ACTIVITY RESTRICTION Property
Class>TOTAL.LOAN.REPAY.TOLERANCE
 Set a periodic attribute for restricting the Prepayment Restriction amount
during the Life of an arrangement
 Use Admin Menu > Product Builder > Product Conditions >ACTIVITY
RESTRICTION Property Class
 Create a new Product Condition

 Set the rule to restrict Prepayment of the Deposit to 40 Percent
 (DEPOSITS-APPLYPAYMENT-PO.CURRENT)
 If user attempts to break the rule Override message to be
displayed with a Charge
 All Attributes are not negotiable by default
Set a Periodic Attribute under Activity Restriction Property Class for restricting
the Prepayment Restriction Amount. This is to be attached to your existing
Activity Restriction product condition

T3TAAD - R18 220
1
221
Set a Periodic Attribute under Activity Restriction Property Class for restriction
in Prepayment Amount
In the periodic attribute set the following:
Rule to be applied for Life of the arrangement
With effect from start date of arrangement

T3TAAD - R18 221
2
222
•Attach the periodic attribute, created now, to the Activity Restriction Product
condition created earlier under the tab Rules
•Record Id of Periodic Attribute is input under Periodic attribute, Activity as
DEPOSITS-APPLYPAYMENT-PO.CURRENT and the value as 40
•and the result for breaking the rule is Override Message with a Charge Property
attached to it

T3TAAD - R18 222
Quiz 4 – Answer the following 22
3
223
Quiz 1. TRANSACTION.AMOUNT.MAXIMUM Periodic Attribute Class can be used to

restrict the Term Amount
a) True
b) False
2. Periodic Attribute Classes are linked to Properties

a) True
b) False
3. Periodic Attribute Class is not a Property Class

True
a)
False
b)

T3TAAD - R18 223
4
224
Conclusion  We have now learn about advanced

parameters
 Constraint Property Class
 Periodic Attributes in Property Classes
 Activity Restriction Property Class

T3TAAD - R18 224
22 22
5 5
225
Deposit Renewal,
Early Redemption and
Closure Setup

T3TAAD - R18 225
6
226
Objectives In this learning unit let us discuss about the
 Change Product Property Class
 Closure Property Class

T3TAAD - R18 226
CHANGE PRODUCT Property Class 22
7
227
Payment
Customer
Schedule
Account Closure
Deposits
Activity
Officers
Restriction
Tax Accounting
Activity Change Activity Periodic

Presentation Product Charges charges
CHANGE.PRODUCT is an optional Property Class of DEPOSITS Product

Line. It can be used to rollover Deposits or to change an Arrangement’s Product
after a certain period.

T3TAAD - R18 227
Change Product - Overview 22
8
228
 Property class is Date specific and TRACKING Type
Property
Attributes Class for
Types
CHANGE
DATED, TRACKING PRODUCT
CHANGE.PRODUCT Property Class is DATED and TRACKING type.

This property class is used to rollover deposits. On the renewal date, user has an
option to Rollover the outstanding Principal amount or part of it.

T3TAAD - R18 228
Change Product – Product Condition 22
9
229
 Allowed Product
 Products to which switch is allowed
 If left blank switch is permitted to all products
 Switch is permitted only within the same product group
 Scheduled Switch of existing Arrangements to a different product

 CHANGE.DATE Field - Switch on a specific date, Date Convention ignored
 CHANGE.PERIOD Field - Switch after a particular period
 PRIOR.DAYS Field - Switch in advance to Switch Date by these days
 Change product event happens in advance of Schedule Date

 Effective Value of Switch is Schedule Date
 e.g. Switch on 26 APRIL effective 01 MAY
 Switch can be Automatic or Manual
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. Should be a valid product in AA.PRODUCT table.
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.

T3TAAD - R18 229
Change Product – Product Condition 23
0
230
 Change Activity
 Activity to be triggered on renewal of arrangement
 Mandatory if renewal date is specified
 Activities allowed are ROLLOVER, RESET and CHANGE.PRODUCT
 Change to Product
 Product to which arrangement to switch to on a date or a period
 Existing Arrangements can be changed to a different product

 This can be done manually or it can be scheduled
 Majority of conditions are overwritten by the new Product defaults

 Exceptions are: Customer, Account, Term Amount and Limit
CHANGE.ACTIVITY - This Field will determines which Activity will be

triggered during Deposits 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 and Term Amount.
Deposits 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 recalculation
of Renewal Date / Maturity Date.

T3TAAD - R18 230
Change Product – Deposit Renewal Activities 23
1
231
 ROLLOVER
 Renewal with existing arrangement conditions or with revised conditions
 Product conditions with TRACKING Option alone will be tracked
 RESET
 Reset happens on Payment end date
 Resets product conditions based on reset set up at product level for different
properties
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 when the New Arrangement(If Change Product Property is
attached to the Product) is rolled over.
RESET would reset to product conditions based on reset set-up at product level
for different properties. The activity chosen by the user to happen on the renewal
date is RESET and resetting should happen on payment end date. 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.

T3TAAD - R18 231
Change Product – Deposit Renewal Activities 23
2
232
 CHANGE PRODUCT
Resets to product conditions of the new product

Based on reset set-up at product level of old product for different properties

User initiated activity happens on renewal date


 Effects of DEFAULT.ATTR.OPTION on CHANGE.CONDITION Activity

Change conditions would happen only when DEFAULT.ATTR.OPTION Field is set RESETTING

If set NON-RESETTING or NONE, new condition will not take effect for arrangement

 RENEGOTIATE
Activity used to change the arrangement conditions of different properties at one stretch

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.
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
DEPOSITS-RENEGOTIATE-ARRANGEMENT can be used to change the
arrangement conditions of different properties at one stretch.

T3TAAD - R18 232
Change Product – Product status 23
3
233
 Status of the product specified in AA.ARRANGEMENT
 PROCESSED – when arrangement moves from old product to new product,

status of old product is updated as PROCESSED
 CURRENT – Status indicates arrangement is running on the current product
 SCHEDULED – If the product is scheduled for a future date, status is updated

as SCHEDULED
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.

T3TAAD - R18 233
Workshop 23
4
234
 Use Admin Menu > Product Builder > Product Conditions > CHANGE.PRODUCT
 Change period is 6 months
 Set DEPOSITS-RESET-ARRANGEMENT activity for Change activity
 Switch to happen 3 days in advance to Change Period
Create a Change Product Product condition.

T3TAAD - R18 234
235
In this workshop, we will see how to create a Change Product Product condition.
Change period is 6 months
Set DEPOSITS-RESET-ARRANGEMENT activity for Change activity
Switch to happen 3 days in advance to Change Period

T3TAAD - R18 235
Closure Property Class 23
6
236
Payment
Customer
Schedule
Account Closure
Deposits
Activity
Officers
Restriction
Tax Accounting

CLOSURE Property Class handles closure of arrangements for DEPOSITS

product line. The reversal of new arrangement activity results in creation of an
ACCOUNT.CLOSURE request for the arrangement account.
After creating a new arrangement for deposit, there are occasions, when a
customer does not want to proceed with the deposit and wants to cancel the
same. For this, user should trigger DEPOSITS-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 DEPOSITS-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.

T3TAAD - R18 236
Closure – Property 23
7
237
 Handles closure of Arrangements
 Property can be viewed and values can be edited
 Product condition is Dated and Tracking
Property Class
Attributes
Types for
DATED, TRACKING CLOSURE
CLOSURE Property class is DATED and TRACKING type.

This property class does not have any related financial balances.

T3TAAD - R18 237
Closure – Product Condition 23
8
238
 Closure Type
 MATURITY - Closure processing would depend on maturity date
 BALANCE - When all balances become Zero closure activity is scheduled
 Closure Method
 Valid options are Automatic, Manual and Online
 Specifies whether closure processing would be triggered automatically or manually or Online
 Closure Period
 Indicates when CLOSURE activity would be processed for Automatic closure
 Posting Restrict
 Specifies the account closure posting restriction code
From R16, it is possible to simulate the closure amount during which settlement conditions
can be updated.
CLOSURE.TYPE Field - Valid options are MATURITY or BALANCE.

If MATURITY is opted closure processing would depend on maturity date. If all
balances are zero on maturity date, closure activity would be scheduled based on
CLOSURE.PERIOD definition.
If BALANCE is opted - As soon as ALL balances become Zero, closure activity
would be scheduled based on CLOSURE.PERIOD.
CLOSURE. METHOD Field - Valid options are Automatic , Manual or Online.
Specifies whether closure processing would be triggered automatically or
manually or Online. Currently online closure is possible only for Accounts
Product Line.
CLOSURE.PERIOD Field - In case of automatic closure, this specifies the
period when the CLOSURE activity 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.
POSTING.RESTRICT Field - Specifies the account closure posting restriction
code. This would be used to update ACCOUNT.CLOSURE application.
Based on CLOSURE.TYPE definition, arrangement status would be flagged to
PENDING.CLOSURE.

T3TAAD - R18 238
From R16, it is possible to simulate the closure proceeds of deposits so that customer
can make informed decisions. It is possible to update the settlement instructions at this
stage.

T3TAAD - R18 238
Workshop 239
239
 Use Admin Menu > Product Builder > Product Conditions > CLOSURE
Closure to happen automatically on maturity
Period for processing after 0 days
Posting restriction code is 90
All attributes are negotiable by default
Create a Closure Product condition for closure on maturity.

T3TAAD - R18 239
0
240
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 0 days
Posting restriction code is 90
All attributes are negotiable by default

T3TAAD - R18 240
Workshop 24
1
241
 Use Admin Menu > Product Builder > Product Conditions > CLOSURE
Closure to happen automatically when all balances become zero
Period for closure processing is 10days
Posting restriction code is 90
All attributes are negotiable by default
Create a Closure Product condition for closure on balance becoming zero .

T3TAAD - R18 241
2
242
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
Posting restriction code is 90
All attributes are negotiable by default

T3TAAD - R18 242
24
3
243
Early Redemption

T3TAAD - R18 243
Simulation of Closure and settlement update 24
4
244
From R16
 Simulation triggered on Request closure
 Closure bill simulated for the date specified
 Redemption Statement generated – available in Overview
 Actual redemption performed – Choice of Settlement account displayed
 Settlement instructions may be updated if required
 Maturity proceeds settled as mentioned – record moved to

PENDING.CLOSURE
 Closure will be based on closure conditions discussed earlier
Redeem Deposit option triggers a simulation process. Upon choosing the date
simulation is triggered for that closure date.
A “Redemption Statement” is produced and is available in the Overview screen.
This statement will includes any transactional charges and cost involved with
redeeming the deposit early. The total amount payable is displayed.
The statement has an “Icon” to complete the transaction if required. Based on
the “Redemption Statement” the customer can make an informed choice.
Customer may or may not proceed with the closure based on the redemption
statement information.
When the actual redemption is selected, the settlement accounts will be
produced.
That is when DEPOSITS-REDEEM-ARRANGEMENT is triggered, the
settlement property of the account is displayed.
The settlement details / accounts can be amended if required.
The transaction can be completed and deposit will move to
PENDING.CLOSURE and the deposit will mature based on Closure conditions
discussed earlier.

T3TAAD - R18 244
Workshop – Deposit Redemption 24
5
245
 Pick a deposit arrangement
 Customer desires to know pre-closure amount on a date
Preclosure of a Deposit through Simulation

T3TAAD - R18 245
6
246
Select the deposit arrangement and click on request closure.

Ensure simulation is switched on
Here we find that deposit is chosen for redemption on current date and it is
Executed Successfully

T3TAAD - R18 246
7
247
Here we find that deposit is chosen for redemption on current date and it is
Executed Successfully
We can find the Redemption statement and breakup of the redemption amount
It is optional to execute it.
When executed, the redemption option open up.

T3TAAD - R18 247
8
248
The settlement instructions may be amended if required and the information of

charges are displayed.
Upon accepting the override the deposit redemption amount is transferred to
account given as per redemption statement.

T3TAAD - R18 248
9
249
Now deposit is pending closure and will close based on closure product
condition details. We an find that the principal and interest is already paid out
CURBALANCE is not there anymore.

T3TAAD - R18 249
Workshop - Partial Withdrawal 25
0
250
 Pick a deposit arrangement
 Simulate a partial redemption and look at the results
Pick A deposit arrangement

Simulate a partial redemption and look at the results

T3TAAD - R18 250
1
251
Select a Deposit arrangement which has been funded earlier than today. Click
the icon Withdraw Deposit.
Ensure that the simulation service and service manager are at START and the
service agents are started.

T3TAAD - R18 251
2
252
Simulation of partial withdrawal is triggered for the desired amount.

T3TAAD - R18 252
3
253
We can find the withdrawal Statement in the Arrangement overview screen.

T3TAAD - R18 253
Workshop solution 25
4
254
The withdrawal Statement information can viewed. When there is more than one
simulation done, all of the simulations are seen here.
The Itemised information property wise can is displayed on the selecting the
desired withdrawal statement.
The desired partial withdrawal can be executed.

T3TAAD - R18 254
5
255
We can see the partial withdrawal is executed and the same is witnessed in the
Arrangement overview screen.

T3TAAD - R18 255
Quiz – True or False 25
6
256
Quiz 1. In order to perform a Early redemption of deposit, the Payoff

Property class is used
True
a)
False
b)

T3TAAD - R18 256
7
257
 Change Product Property Class
 Closure Property Class

T3TAAD - R18 257
25 25
8 8
258
Accounting and
Balance Maintenance

T3TAAD - R18 258
9
259
Objectives In this learning unit let us discuss about the
 Accounting Property Class
 Balance Maintenance Property Class
 Data Migration Steps
 Reporting Property Class

T3TAAD - R18 259
260
260
AA Advanced Accounting

T3TAAD - R18 260
AA Accounting –overview 26
1
261
Arrangement Accounting
Activity Events
Accounting
Property Product Action
Condition Financial
Reporting
Balance 1
Allocation
Balance 2 Rules SPEC.ENTRY
Balance ‘n’
STMT.ENTRY
Update CATEG.ENTRY
Balances
In T24, Accounting entries are automatically generated for authorised

transactions.
AA provides a certain amount of flexibility in defining broad rules for a desired
accounting set-up.
When an Activity involving accounting is processed, that will raise an
Accounting event.
Accounting Property Class is used to define Property-wise and Action-wise
Allocation Rules.
Further, Properties having a financial implication like Interest, Charge, etc. can
have multiple Balances which can be defined by Users.
Allocation Rules define the rules for debit and credit transactions of every
accounting event type like which type of entries need to be generated, the
balances to be updated, etc.
T24 core accounting will raise the necessary accounting entries (Spec Entry,
Stmt Entry and Categ Entry) and will update the required balances as set in the
Allocation Rules.
These balances will be consolidated and can be reported in Financial Reports.

T3TAAD - R18 261
Arrangement Balances - Overview 26
2
262
 Some Properties of an Arrangement have one or more associated Balances

 A property can have Balances in different states depending on status
 Some activities update Balances

 Balances are updated through T24 accounting
 Balances are used

 In financial reporting
 As the basis for calculation of interest or charges
 For applying certain types of periodic restriction
Some of the Properties of an Arrangement have one or more associated

Balances. Each of these balances represent financial values.
Depending on the ageing status of a Property with a Balance, different
Balances can be maintained for it. For example, the ACCOUNT Property will
have balances like CURACCOUNT, DUEACCOUNT, EXPACCOUNT, etc.
When you process some Activities for an Arrangement, they will result in
updating these Balances.
T24 Accounting does the update of Balances. These balances are used for
different purposes such as interest calculations, charge calculations, to check
periodic restrictions and financial reporting.
Balance Types represent the financial components of a Product; Balances are
associated with the Properties of a Product. For example, for a Product with two
INTEREST Properties, say DEPOSITINT and PENALTYINT, AA will maintain
for each Property, its own set of Balances.
Balance types may be defined as types to be reported (as contingent or non-
contingent) or as an internal type that is not used for any reporting. In other T24
applications, the balance types have been hard-coded.

T3TAAD - R18 262
AC.BALANCE.TYPE 26
3
263
 Balance Type is a Financial Component of a Product

 Definition of Product specifies which balance types the Product should be comprised
of
 Reporting Type -Contingent, Non-contingent and Internal
 Balance types are hard coded in T24
 AC.BALANCE.TYPE application offers ability to create additional balance types

and define relevant characteristics
 Decompose Balance Types
 Post or suppress entries for Internal Balance Types
 Post to Internal Balance Type
 Existing Balance types used by the system cannot be changed via AC.BALANCE.TYPE
application
AC.BALANCE.TYPE: Balance Types represent the financial components of a

product; the definition of the product specifies which balance types the product
should be comprised of. Balance types may be defined as types to be reported
(as contingent or non-contingent) or as an internal type that is not used for any
reporting.
These balance types have been hard-coded within T24 application. In order to
make T24 accounting softer to the user, the AC.BALANCE.TYPE application
offers the ability to create additional balance types and to define the relevant
characteristics of the balance type.
Some of these characteristics include the ability to decompose Balance Types, to
post or to suppress entries for Internal Balance Types or to post to internal
balance Types.
Note: Existing Balance types used by the system cannot be changed via this
application.

T3TAAD - R18 263
Balance Prefix 26
4
264
Possible Prefixes for Deposit

Product Line:
CUR = Current Balance
TERM.AMOUNT, ACCOUNT
ACC = Current Accrued

Balance
INTEREST, CHARGE
DUE = Due Balance

ACCOUNT, CHARGE
AGE = Overdue Balance

ACCOUNT
UNC = Unallocated Credit

ACCOUNT
UND = Unallocated Debit

ACCOUNT
EXP = Expected Balance

ACCOUNT
PAY = Payable Balance

ACCOUNT, INTEREST, CHARGE
Balance prefixes are identified in PROPERTY CLASS table. Users cannot

update them. AA provides flexibility to create Properties and Balance Types that
are linked to those Properties. Balance Type prefix is 3 alphanumeric characters.
CUR - Current or live value of Property Balance –example, current Principal
Balance. In case of AA Deposit, Principal balance is held by ACCOUNT
Property. If ACCOUNT is a Property of ACCOUNT Property Class, then
Balance Type of principal balance will be CURACCOUNT.
ACC - Current accrued Balance for Property - this is relevant for Properties
which represent P&L items like Interest, Charge related Properties.
DUE - Due Balance for Property – this is when a Property has been made due in
a Payment Schedule. In case of P&L Properties like Interest, Charges when it is
made due, the Balance will move from accrued balance to due balance. In case
of Principal Balance, it will move from current balance to due balance.
AGE – For an aged balance prefix will be determined by the overdue status.
UNC – This is applicable only to Account Property and represents unallocated
or paid in excess credits. UND - This is applicable only to Account Property and
represents unallocated debits. EXP – Applicable only to Account Property,
represents expected balance from the customer. PAY – Represents amount
payable by Bank to customer or by customer to the Bank.

T3TAAD - R18 264
AC.BALANCE.TYPE 26
5
265
 Balance Types
Contingent -Reported as Contingent - Off-Balance Sheet Item

Non-Contingent - Reported in Balance Sheet


Internal - Not to be used for Reporting


Virtual

 Summation of specified balances

 Used for calculation purposes
 Activity Update - Option to update dated historical

balance file (ACCT.BALANCE.ACTIVITY)
 Suspend Balance - Option to suspend posting to PL
We will now look at the AC.BALANCE.TYPE, where various Balance types are
defined, to understand its fields.
The REPORTING.TYPE field defines how this balance should be used with
respect to reporting.
CONTINGENT - reported as a contingent i.e. off-balance sheet items. NON-
CONTINGENT - reported as on balance sheet items.
INTERNAL are not to be used in reporting. VIRTUAL is a summation of
balances, used internally in AA products, mainly for calculation purposes.
ACTIVITY.UPDATE field specifies whether a dated historical balance file
(ACCT.ACTIVITY) should be updated when this balance type is updated. For
some types of balance (e.g. accruals) there is no need to maintain a dated
history. This is not allowed for Virtual balances.
If the Balance type is to be suspended, it can be set in SUSPEND.BALANCE.
In this case, a Balance type record with suffix SP should be created.

T3TAAD - R18 265
Workshop 26
6
266
 Use User Menu > Retail Operations > Product Catalog > Product Groups > Term Deposits >
Short Term Deposit
 Create a new Arrangement and get it authorised. While authorising note down the AA Account Number
 Use Command Line

 Look at EB.CONTRACT.BALANCES, ACCT.BALANCE.ACTIVITY
 Use User Menu > Retail Operations > Deposits Transactions > Arrangement Activities (FT) >
AA Deposit - Fund
 Deposit commitment amount using FT and get it authorised
 Use Command Line

 Look at the ACCT.BALANCE.ACTIVITY, EB.CONTRACT.BALANCES and Arrangement Balances
Creation of a New Arrangement and view the

EB.CONTRACT.BALANCES,ACCT.BALANCE.ACTIVITY and ACCOUNT
Balances Before and After Funding the Deposit Arrangement

T3TAAD - R18 266
7
267
In this workshop, we are going to create a new Arrangement for an amount of

USD 100000 for a period of 1 Year and get it authorised

T3TAAD - R18 267
8
268
Use Command Line and

Look at the EB.CONTRACT.BALANCES,
ACCT.BALANCE.ACTIVITY, account record and Balances

T3TAAD - R18 268
9
269
Deposit the commitment amount using FT and get it authorised

T3TAAD - R18 269
0
270
After Authorising the Deposit amount


T3TAAD - R18 270
1
271
.
After Authorising the Deposit amount


T3TAAD - R18 271
Linking Balances to Calculations 27
2
272
 Interest and Charge properties can base their calculations on specific balances
 This can include virtual balances
 And can include ‘memo’ balances
 Provides a variety of calculation options
User can define different balances. It includes virtual balances – sum of

selected balances; memo balances such as undrawn commitment balances, etc.
and use them for different calculation purposes.
Interest can be calculated on current deposit balance, Penalty interest on
expected, overdue balances, Fees on original / commitment balances, etc.

T3TAAD - R18 272
Linking Balances to Calculations 27
3
273
 Specify Properties and Balances linked for calculations in

CALCULATION.SOURCE Tab in Product (AA.PRODUCT.DESIGNER)
Set Calculation property , Source Balance and Source Type
Link to AC.BALANCE.TYPE is made through Source Balance
CALC.PROPERTY Field is used to specify properties requiring calculations.

(e.g. DEPOSITINT propertie require calculation of interest).
Calculation is based on a BALANCE indicated in SOURCE.BALANCE Field.
This should be a valid AC.BALANCE.TYPE Id.
SOURCE.TYPE Field indicates whether calculation is based on Minimum,
Average or Daily balance for AA Deposits. The data for this field should be a
valid record in AA.SOURCE.CALC.TYPE.
In the above example DEPOSITINT will use CURACCOUNT Balance type for
calculation.

T3TAAD - R18 273
AA.PROPERTY.CLASS.ACTION 27
4
274
 This application holds information on actions performed in each PROPERTY

CLASS
 The information covers:

 Actions for each PROPERTY CLASS
 Accounting entry generated or not for the action
 Product Line
AA.PROPERTY.CLASS.ACTION – This application holds information on

actions which can be performed with a PROPERTY CLASS.
It also indicates whether the action will generate an accounting entry and which
Product Line is affected.
Note: Till R9, this information was available as part of Property Class record in
the application AA.PROPERTY.CLASS. Now each action will have an
individual record associated with it in the new application
AA.PROPERTY.CLASS.ACTION

T3TAAD - R18 274
Activities Overview 27
5
275
 Activities are operations that can be applied to Arrangements

 Example : Deposit, Apply Payment, Accrue Interest
 Arrangements can only be updated via Activity (both online and COB)
 In fact, creating a new Arrangement is also an activity
 Activities are grouped into Activity Classes

 Defined by Temenos
 Activity Class defines behaviour
We will begin with a review of what we have learnt about Activities earlier in
the AA core course.
1. Activities are operations that can be applied to Arrangements

Example : Deposit, Apply Payment, Accrue Interest
Arrangements can only be updated via Activity (both online and COB)
In fact, creating a new Arrangement is also an activity
2. Activities are grouped into Activity Classes
Defined by Temenos
Activity Class defines behaviour

T3TAAD - R18 275
Activity Class Actions- DEPOSIT-CHANGE-INTEREST 27
6
276
Update Interest
Evaluate Activity Restriction
Calculate Activity Charges
Send Message Activity Messaging
Evaluate Alerts
Actions Property Classes
Slide 276
An Activity Class is actually comprised of a number of smaller steps which we

refer to as Actions, which act on Property Classes.
In the Deposit - Change - Interest Activity Class, we have the following Actions:
First is to update the changed interest rate which acts on the Interest Property
Class. Next is to evaluate whether any activity restrictions exist and how they
are affected. This acts on the Activity Restriction Property Class. Then the
Calculation Action acts on the Activity Charges Property Class, to calculate
charges, if any for the activities. Next, sending a message is effected by acting
on Activity Messaging Property Class. Finally evaluation for alerts acts on
Alerts Property Class.
Similarly DEPOSITS-ACCRUE-INTEREST is an activity class, comprising of
Accrue action on Interest Property Class and Calculate action on Activity
Charges Property Class. Here, accruals can be set to run at frequencies like
daily. Please note that, to prevent creation and accumulation of too many
records, when set to accrue daily, this activity reuses a unique id for accruals
created on AAA.

T3TAAD - R18 276
Activity - DEPOSIT-CHANGE-DEPOSITINT 27
7
277
Update DepositInt
Evaluate Activity Restriction
Calculate Activity Charge
Send Message Activity Messaging
Evaluate Alerts
Actions Properties
Slide 277
You know that an Activity is an occurrence of an Activity Class which acts on a

Property. Here Depositint is a Property of the Interest Property Class.
You can see here that Actions are performed on Properties.
Actions performed by Properties on an arrangement can result in the movement
of one or more balances associated with that property. When a balance
movement is required the Action will generate an accounting event.

T3TAAD - R18 277
Accounting Property Class 27
8
278
Payment
Customer
Schedule
Account Closure
Deposits
Activity
Officers
Restriction
Tax Accounting

ACCOUNTING is a mandatory Property Class of DEPOSITS Product Line. It is

used to specify the soft accounting rules.

T3TAAD - R18 278
Accounting - Property Class 27
9
279
 Property for Accounting cannot be viewed or edited at arrangement level
 Update Action possible.

 Will not generate Accounting entry
Property Class
Type for
DATED, MERGE, TRACKING.ONLY ACCOUNTING
The ACCOUNTING component is used by all products which require

accounting. Products serviced through AA use activity-based accounting. This
component allows for the definition of the allocation rules to use for each action.
Each Property can have multiple Actions which require accounting. For each of
these actions the user must specify the allocation rule (defined in
AC.ALLOCATION.RULE) which will be used each time the action is run.

T3TAAD - R18 279
Accounting – Product Condition 28
0
280
 Rules defined for every property requiring accounting entries

 Allocation rules defined for each action of property
 ACCT.ACTION Field - Accounting Action

 Action of respective properties for which rules are defined
 Must be ACTION having ACCOUNTING stated to YES in AA.PROPERTY.CLASS
 ACCT.RULE Field - Allocation Rule

 Accounting rule associated with property and accounting action
 Must be a valid record in AC.ALLOCATION.RULE
 PROPERTY Field
 Indicates the Property to which following accounting rules apply
ACCT.ACTION Field indicates action for which rule is defined. A Valid action
for the property needs to be stated. System would validate the action stated with
list of actions stated in AA.PROPERTY.CLASS to which the property belongs.
It is expected that all ACTIONs which have ACCOUNTING stated as YES
should find a rule in this table. This field is part of a multi value set with
PROPERTY and ACCT.RULE.
ACCT.RULE Field indicates accounting rule that is associated with the
PROPERTY and ACCT.ACTION within the same multi value set. This field is
part of a multi value set with PROPERTY and ACCT.ACTION. Input must be a
valid record from AC.ALLOCATION.RULE.
PROPERTY Field indicates the Property to which the following accounting
rules apply. Note that properties may be specified that are not used by products
linked to this condition. This is to allow the accounting property to be inherited
by multiple products. This field is part of a multi value set with ACCT.ACTION
and ACCT.RULE. Input must be a valid record in AA.PROPERTY.

T3TAAD - R18 280
1
281
 Charges / Commission taken can be amortised over a period specified in

Accounting property
 Amortisation is possible for Due as well as Pay charges
 Accrue Amort
This should be set as AMORT
 Accrue Period
Should be set as MATURITY or RENEWAL or a valid period to be defined (1M, 1Y)
Charges can be amortised by setting ACCRUE.AMORT field as AMORT and

the ACCRUE.PERIOD either as MATURITY or defining valid period (like 1M,
1Y, etc) in AA.PRD.DES.ACCOUNTING.
Amortisation is possible for due and pay charges also. The core accounting
system will do amortisation for ACC balance during cob as per the frequency
defined in AA.ACCRUAL.FREQUENCY record. For example, for pay charges,
the ACC balance would be amortised by the core accounting during COB. The
job EB.COMM.ACCRUAL under the batch SYSTEM.END.OF.DAY raises
amortisation entry (Dr PL category & Cr ACC<CHARGE>) during close of
business.
Booking of charge to income (P&L) will be amortised and the income will be
distributed to periods based on the amortisation term set in
AA.PRD.DES.ACCOUNTING record and accrual frequency set in
AA.ACCRUAL.FREQUENCY for the specific CHARGE property.
Any charge/commission taken, can be amortised, over a period specified in the
accounting property.
From R15, Amortization period can be set to ‘Renewal’ or “Maturity” or a
definite period.
Amortization of charge will be done until renewal date i.e., end date in
EB.ACCRUAL record will be updated with next renewal date.

T3TAAD - R18 281
In case renewal date is not available maturity date will be used for amortization. This
can happen when renewal conditions are not defined or the contract is in the final
rollover period. In case of a call contract, whenever the charge is made due system will
throw an override “Amortization not supported for Call / Notice”. When renewal date
changes, the remaining unamortized amount is amortised till new renewal date. Note, a
change product manually captured, any remaining un-amortized amount will be
recognized to PL on the same day.

T3TAAD - R18 281
2
282
 Separate Profit and Loss Posting for Negative Interest Rate.
 Allowed only for Interest Property/ Property Class.
 If the fields are left blank, Income / expenditure will be booked to the
same P&L category used when the rate is positive.
 During accrual adjustment for current month, the default behaviour of

posting income/ expenditure to P&L configured in ADJUST.CM field will
be followed.
 Income / Expenditure will be posted to suspended balances as usual even

if the rate is negative.
From R18, Separate P&L Posting for Negative Rates can possible to configure
using Accounting Property Class Product Condition.
Report Interest Income/ Expenditure separately when the interest rate is
Negative using the fields
PC.NEG.BOOKING.CM, PC.NEG.BOOKING.PM, PC.NEG.BOOKING.PY
for Property Class; NEG.BOOKING.CM, NEG.BOOKING.PM,
NEG.BOOKING.PY for Property.
At arrangement overview screen we can find negative and positive interest

separately.
Tax can possible to configure Net accruals or Positive accruals or Negative
accruals through TAX.CODE.PARAMETER and Tax product condition.
Interest accruals table added total positive accrual amount and total negative
accrual amount for capitalization period.

T3TAAD - R18 282
3
283
Example 1 - Positive Rate of 1% for the entire Interest capitalization period

Dr Interest Expense ($2,500.00)
Cr Interest Payable / Receivable $2,500.00
Example 2 - Negative Rate of -1% for the entire Interest capitalization period
Dr Interest Payable / Receivable ($2,500.00)
Cr Interest Income (Negative Rate) $2,500.00
Example 3 - Rate Changes from Positive 1% to Negative -1% within a capitalization period
Interest Amount (Positive Rate) : $1000
Interest Amount (Negative Rate) : ($1500)
Dr Interest Payable / Receivable ($500.00)
Example 4 - Rate Changes from Positive 1% to Negative -1% within capitalization period
Interest Amount (Positive Rate) : $1500
Interest Amount (Negative Rate) : ($1000)
Cr Interest Payable / Receivable $500.00
During a Capitalisation period for a positive Interest rate, the Interest expense
can be debited, whereas for a Negative Interest rate the Interest Income can be
credited.
But during a Capitalisation period when the rate moves from Positive to
Negative(or vice versa), the Expense and Income is booked to respective PL and
the net amount is billed. (either debit or credit depends on the net amount).

T3TAAD - R18 283
4
284
 From R17, Charges /Commission can be accrued in AA
 Accrual period will be same as the frequency given in Payment Schedule

for the charge.
 ACCRUE.AMORT field to be set as Accrue and ACCRUE.PERIOD field to be

set as Schedule to perform accrual until next schedule date
 Back dated changes to the Charge amount or Payment Schedule will

result in reversal and rebooking of the accruals.
 PL to which the charges are booked and against which company are
configurable
From R17, Charge Accrual can be configured using Accounting Product

Condition. Property Specific choice or Charge Property Class can be set up to
Accrue in AA.
For the charge property or Property Class, the field ACCRUE.AMORT to be set
as Accrue and ACCRUE.PERIOD field should be set as Schedule to perform
accrual until next schedule date.
ACCRUE.PERIOD should be SCHEDULE for ACCRUE option and other
options are not allowed.
If the property is type is set as Rebate unamortized, Accrual cannot be set up the
same.
The Accrue Period “SCHEDULE” simply means that the Accrual Period will
follow whatever the Schedule is, for that Property. This also means that the
Schedule itself could be a relative date (relative to Maturity or Renewal) or a
fixed schedule or fixed periods (Last Day of the Month/Quarter etc). The option
‘SCHEDULE’ is allowed only for Charge Accruals and not applicable for
Charge Amortisation.
If during assessment (scheduled or closure), because of a Charge Routine or a
Charge Adjustment Routine, if the charge amount is different to what was
initially set to be accrued, appropriate adjustments will be done by the system

T3TAAD - R18 284
based on the new amount.
For Back dated changes to Charge amount or payment Schedule, the accrual amount has
be correct in EB.ACCRUAL by reversal and rebooking of the accruals. Note that,
Accruals are never reversed and replayed but accrual amount will be corrected based on
the changes.
PL category to which the charges are booked and against which Booking Company is
configurable. For Deposits the choices available are to book the charges to customer
company or arrangement company.

T3TAAD - R18 284
Accounting – Product Condition
285
• Possible to have net or itemised entries for Charges that have waiver applied
• Tax can also be booked as itemised entries instead of net entry
• Property Class specific choice or property specific choice is possible for Net or
Itemised entries of Tax or Charges
• Property specific choice overrides property class specific choice.
Slide 285
Until R14 it was possible to segregate the waived charge amount from the
calculated charge amount – either default setup or property class/property
specific.
R15 onwards, Property class or Property specific choice for Charge and Tax is
possible – to book itemized entry or net entry.
Final amount of Charge can be booked after waiver when the choice is Net.
When choice is Itemized the original charge and waiver amount is booked
separately.
From R15, it is possible to book the Tax entries itemized along with interest and
charges and not have them as single entry. This can either be a property or
property class specific choice.
PC.CONSOLIDATION - Charge / Tax Property Class with a specific method for
raising entries for which we can define PC.CONSOL.METHOD as ‘Net’ or
‘Itemized’
CONSOLIDATION - Charge / Tax Property with a specific method for raising
entries. This is used override the method defined at the property class level.
CONSOL.METHOD - Method that applies to the associated Interest / Charge
Property. The options are identical to PC.CONSOL.METHOD

T3TAAD - R18 285
The default value for property class specific choice is NET. Possible to make it Itemised
if necessary.

T3TAAD - R18 285
Accounting Balances and Data 28
6
286
Current balances
ARRANGEMENT EB CONTRACT
ID: Arrangement No.
BALANCES
1 ID: AA Account ID
Arrangement
Master
Current balance amounts STMT.ENTRY
Account No = Arr A/c
Balance Type = Multi Bal Type
1
ACCT
ACCTACTIVITY
ACTIVITY
ACCOUNT ID: Contract/Account
ACCT.BALANCE.ACTIVITY
ID: Contract/Account
[.balance] - YearMonth
ID: Contract/Account
ID: Account [.balance] - YearMonth
* [.balance] - YearMonth CATEG.ENTRY
Hist Balance and mvmt
Working Balance Hist Balance and mvmt Account No = Arr A/c
Hist Balance
By value dateand mvmt
By value date Profit and Loss Movement
By value date
Link to T24 apps
Crf Key Data
Historic Balances Accounting Entries
Interest Calc
SPEC.ENTRY
Deal No = Arr A/c
CRF Type = Multi Bal Type
Arrangement account maintains working balance and is linked to

EB.CONTRACT.BALANCES by the Account ID.
EB.CONTRACT.BALANCES holds current balance amounts for various
balance types and its ID is the AA Account ID.
Historical data are maintained in ACCT.ACTIVITY. Maintenance of
ACCT.ACTIVITY for a Balance type is optional.
ACCT.BALANCE.ACTIVITY holds ACCT.ACTIVITY data by AA account
balance type.
Accounting events generate, STMT, CATEG and SPEC entries.
STMT.ENTRY – a movement to T24 account balance.
CATEG.ENTRY – a profit and loss movement with a specific profit and loss
category.
RE.CONSOL.SPEC.ENTRY – a movement to an Arrangement with a specific
balance type.
Default SYSTEM.ID updated in STMT.ENTRY, CATEG.ENTRY,
RE.CONSOL.SPEC.ENTRY for an AA transaction is AAAA.

T3TAAD - R18 286
AC Allocation Rules and AC Posting Detail 28
7
287
 Allocation Rules take an event and creates a number of entries by specifying

 Target Balance
 Contra Balance
 Transaction Codes to Use
 Movement Detail
 Multiple Targets and Contra Targets can be created from same event
 Will allow additional movements to be created if required
 Target options include P&L, Internal Account, specific Balance Type
 Default is balance type supplied with the entry through AC.POSTING.DETAIL
 Posting Detail allows detailed content of the entry to be defined

 Entry type
 References, Narratives etc
An accounting event raised by an action is the basis for generation of actual

accounting entries.
In T24 three types of Accounting entries can be generated, and certain
mandatory information like Transaction Code, PL Category, etc. are required to
generate these entries. If different transaction codes for a prepayment and a
regular repayment are to be fed to the interface for a third party reporting
application, a user exit routine in AC.POSTING.RULE can be set to manage
different transaction codes.
An Allocation rule is used to specify the types of entry and target account,
balance type or profit and loss category that an accounting event should
generate. It also specifies how the details of the entry record are to be built
including the transaction code to be used. Allocation rules are defined in the
table AC.ALLOCATION.RULE.
It is also possible to create multiple entries and contra entries from an
accounting event.
Each accounting entry contains a number of detailed fields. Certain details in the
entries generated as a result of the application rules can be configured, for
example, System Id; Customer Narrative; Customer References; Internal
References. The mapping details to the fields of Accounting entries are defined
in the AC.POSTING.DETAIL table and linked to each Accounting event defined

T3TAAD - R18 287
in the AC.ALLOCATION.RULE.

T3TAAD - R18 287
Accounting entries in AA 28
8
288
 When an Arrangement is debited / credited

 Original entry from underlying application moved to suspense account
 Opposite entry created from suspense when processing activity
 Suspense account replaced with balance type AASUSPENSE
 Internal balance type AASUSPENSE used in both core and soft accounting
 Shift from suspense account to AASUSPENSE improves performance and helps

in reconciliation
Each time, an Arrangement (Account) is debited or credited the original entry

from the underlying application is moved to a suspense account, and an opposite
entry is created from the suspense when the activity is processed. Till R11, two
additional accounting movements were raised, thus the volume of entries across
the suspense account was high. In R12, suspense account has been removed,
thus helping in reconciling and improving performance.
The accounting processing related to AA no longer generate entries to a
suspense account but instead use an intermediate balance type AASUSPENSE
that belongs to the Arrangement Account. This will remove an additional set of
entries for the suspense account, this internal AA balance type AASUSPENSE is
used both in the core and soft accounting sides.

T3TAAD - R18 288
AA and Accounting 28
9
289
Suspense
TELLER Processing
Change A/C on Cr
AASUSPENSE
Dr Till entry to14700
Payment
Cr Arrangement Accounting Rules
USD 1,500.00
AA.ARRANGEMENT.ACTIVITY
STMT.ENTRY Dr 14700
CR1 Arrangement (Principal)
Txn Ref = TT CR2 Arrangement (Interest)
DR Till $1,500 CRx Arrangement (Charge)
Txn Ref = TT (Total=1,500.00)
CR 14700 $1,500
Txn Ref = AA
DR 14700 $1,500
Activity Log
Txn Ref = AA
CR1 Arrangement $xxx
Txn Ref = AA
CR2 Arrangement $xxx
Transaction Boundary
Txn Ref = AA
CRx Arrangement $xxx

T3TAAD - R18 289
Reporting Property Class 29
0
290
 AA module is integrated with Position Management (PM) module using

Reporting Property class
 Configuration of IFRS accounting is possible through Reporting

Property class
AA module is integrated with Position Management (PM) module using

Reporting Property class
Configuration of IFRS accounting is possible through Reporting Property class
Please refer to the ELearning on Reporting Property class for further
information on AA PM integration and IFRS setup.

T3TAAD - R18 290
Balance Maintenance Property Class 29
1
291
Payment
Customer
Schedule
Account Closure
Deposits
Activity
Officers
Restriction
Tax Accounting
Activity Activity Activity Balance

Presentation Mapping Charges Maintenance
BALANCE.MAINTENANCE is an optional Property Class of Deposits

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 Deposits 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.
DEPOSIT-ADJUST.BILL-BALANCE.MAINTENANCE is an activity (class)
for adjusting balance / making the balance ‘0’.

T3TAAD - R18 291
Balance Maintenance - Property Class 29
2
292
 Property class allows to capture bills, balances and adjust balances of bills
taken over from contracts
 Contracts can be taken over from existing legacy system or existing T24
Deposit modules
Attributes into
controlled AA module
by TYPE Field
Property Class
for
Type BALANCE.
DATED, NON.TRACKING, CCY,
MULTIPLE, ARRANGEMENT MAINTENANCE
This Property Class allows to capture bills, balances and adjust balances of bills
taken over from contracts.

T3TAAD - R18 292
Balance Maintenance – Product Condition 29
3
293
Capture Bill
Capture Balance
Adjust Bill
Adjust Balance
Write Off Bill
Write Off Balance
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.

T3TAAD - R18 293
Balance Maintenance – Capture Bill 29
4
294
 Allows a single bill to be captured for an arrangement

 Total OS Amount
 Amount OS by property
 Original Amounts
 Bill Date
 Due Date
 Dates are before start date of arrangement in T24
 Amounts are made due and then will be aged by processing as part of the same activity
 Other ‘side’ of movement is handled by allocation rules – usually suspense or wash account
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.

T3TAAD - R18 294
Balance Maintenance – Capture Balance 29
5
295
 Allows non bill related balances to be captured for an arrangement
 For example accrued interest, charges
 Dates are before start date of arrangement in T24
 Other ‘side’ of movement is handled by allocation rules
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.

T3TAAD - R18 295
Balance Maintenance – ADJUST BILL 29
6
296
 Allows existing bill amounts to be adjusted

Amounts can be increased or decreased
Can be adjusted to zero
 Multiple Bills can be adjusted in the same transaction
 Balance Maintenance property will show balances as per the effective date of the
adjustment activity

Net movement between bills can be zero
Bills captured can be adjusted. They can be increased or decreased or even

adjusted to Zero.
It is possible to adjust multiple bills at a time in a single transaction.

T3TAAD - R18 296
Balance Maintenance – ADJUST BALANCE 29
7
297
 Allows existing non bill related balances to be adjusted

Amounts can be increased or decreased

Can be adjusted to zero


 Multiple Balances can be adjusted in the same transaction
adjustment activity

Net movement between bills can be zero

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.

T3TAAD - R18 297
Balance Maintenance – Write off Bill 29
8
298
 It is an ADJUST BILL activity
 Allows existing bills to be written off

Amounts are automatically set to zero
Bill status set to written off
 Multiple Bills can be written off in the same transaction
adjustment activity
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.

T3TAAD - R18 298
Balance Maintenance – Write off Balance 29
9
299
 Allows existing non bill related balances be written off

 Selected Balances are decreased to zero
 Multiple Balances can be written off in the same transaction
 Balance Maintenance property will show balances as per the effective date of
the adjustment activity
Balances which are not related to Bills can be written off 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.

T3TAAD - R18 299
Balance Maintenance – ADJUST ALL 30
0
300
 Allows adjustment of bills and non bills related balances in the same transaction
Balances and amounts can be increased and decreased
Combination of Adjust Bill and Adjust Balance
 Bills can be written off
 Amounts can be written off

Net effect of adjustment can be zero
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.

T3TAAD - R18 300
Balance Maintenance – Others 30
1
301
Typical sequence of steps involved in migration:
 Take-over Arrangement
 Capture outstanding Principal
 Capture overdue Bills
 Capture current accruals
The recommended steps during migration are - Take-over Arrangement, Capture

outstanding Principal, Capture overdue Bills, Capture current accruals

T3TAAD - R18 301
Balance Maintenance Activities 30
2
302
Take Over Activities – Capture Bills and Balances

Direct Financial Adjustments
User can initiate activities in every arrangement through Arrangement Overview

> New Activity Tab.

T3TAAD - R18 302
Quiz
Quiz 7
30
3
303
Quiz
1. Balance prefixes are indicated in ACCOUNTING Property Class
a) True
b) False
2. Virtual Balance is the sum of selected balances

a) True
b) False
3. Balance Prefixes in AA Deposits are user definable

a) True
b) False

T3TAAD - R18 303
4
304
 Accounting Property Class
 Balance Maintenance Property Class
 Data Migration Steps
 Reporting Property Class

T3TAAD - R18 304
30 30
5 5
305
Building banking products and

Deposit arrangements
(Features of Deposits)

T3TAAD - R18 305
6
306
Objectives In this learning unit let us discuss about
 Features of Deposits arrangements
 Building Banking Products and create

Deposit arrangements

T3TAAD - R18 306
30
7
307
Building Banking Products

T3TAAD - R18 307
AA - Tables used for building Banking Products 30
8
308
 Tables used for building Banking products from re-usable components :

 AA.PRODUCT.LINE
 Designed by TEMENOS
 AA.PRODUCT.GROUP
 AA.PRODUCT.DESIGNER
 AA.PROPERTY and AA.PRD.DES.<PROPERTY.CLASS> set up earlier could be

used across several Products, if the underlying Property class is same
 Composite screens used for building these for ease of operation
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.

T3TAAD - R18 308
AA.PRODUCT.LINE 30
9
309
 High level definition of Business lines

 Defined by indicating the Property Classes that constitute the Business Line
 Used for building blocks to construct Product groups and individual Products falling under the line
 Pre–defined by TEMENOS - Only description can be modified
 For Deposits Product Line, TEMENOS would have set LINE.ATTRIBUTE Field as CCY and
REPLAY - For other lines like Internet services, this would be left blank
 Property Classes that constitute the line are to be marked as Mandatory or not
 For a mandatory Property Class, there should be atleast one Property present in its Product Groups and
Products
 If any Property is to be included at a Product level, its Property class should have been defined at Product
line level – either as Mandatory or Optional
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 DEPOSITS Product Line will enable users to design and
service term loan products -Deposits.
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 whether Reverse and Replay functions
are allowed. This field, for deposits product line, contains a value CCY and
REPLAY. Values possible are CCY, REPLAY and NULL.
MANDATORY field identifies whether inclusion of a Property Class in the
associated multi value field PROPERTY.CLASS is mandatory when creating a
new product in AA.PRODUCT.GROUP and subsequently, in
AA.PRODUCT.DESIGNER.

T3TAAD - R18 309
AA.PRODUCT.GROUP 31
0
310
 Groups of Products are formed from Product Lines - Each Product group has a
number of Properties associated with it - Gives a basic shape to associated products
 Properties can be specified as Mandatory or not at this level - Each Product Group must
have atleast one mandatory Property for each of the mandatory Property Classes of its
Product Line - A mandatory Property should be necessarily defined at Product Level
 Possible to indicate Internal or External as the Group Type - Product Groups of

Bank’s own Products marked as Internal and Groups of other Banks’ Products as
External. External group products used for comparative analysis
 When a Property is added to a Product Group, Activities for the Property are
generated automatically - REBUILD.ACTIVITIES Field to be set as YES
We will now look into how we 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, which 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 Bank's own product. Only those
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 comparative
analysis to show the superiority of Bank's own product. Products of this type are
not available for sale to 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

T3TAAD - R18 310
used to rebuild activities when a new property is introduced into a group.

T3TAAD - R18 310
Workshop– Creation of New Product Group 311
311
 Use Admin Menu > Product Builder > Products > Product Lines –Deposits
Create a new Product Group with the following Settings:
PROPERTY CLASSES PROPERTY MANDATORY
ACCOUNT ACCOUNT YES
ACCOUNTING ACCOUNTING YES
ACTIVITY.MAPPING ACTIVITY.MAPPING YES
CUSTOMER CUSTOMER YES
PAYMENT.RULES PR.DEPOSIT YES
TERM.AMOUNT COMMITMENT YES
PAYMENT.SCHEDULE SCHEDULE YES
CLOSURE CLOSURE YES
PO.WITHDRAWAL YES
PAYOUT.RULES PO.EARLY.WITHDRAWAL
INTEREST DEPOSITINT
ACTIVITY.RESTRICITON ARRANGEMENT.RULES
ACTIVITY.CHARGES ACTIVITY.CHARGES
ACTIVITY.PRESENTATION PRESENTATION
CHARGE DEPADMINFEE
OFFICERS OFFICERS
TAX TAX
PERIODIC.CHARGES PERIODICCHARGES
SETTLEMENT SETTLEMENT
ELIGIBILITY ELIGIBILITY
CHARGE.OVERRIDE CHARGE.OVERRIDE
Create a new Product Group

T3TAAD - R18 311
2
312
In this workshop, we will see a Product Group created by using the existing
properties attached to the Property Class with properties marked as Mandatory
or optional

T3TAAD - R18 312
AA.PRODUCT.DESIGNER 31
3
313
 Products are designed from Product Group through this table
 Each Product to have all the mandatory Properties and any of the optional Properties
associated with its Group. For each Property, Product condition should also be defined
 Possible to link more than one product condition to a Property
 User to define period after which additional conditions to be effective
 Can be defined in Days, Weeks, Months or Years
 Products for Inheritance only
 Non Saleable and acts only as Parent
 Does not undergo Proofing and Publishing validations
 Child Product
 PARENT.PRODUCT Field indicates Parent to the Current product
 Will inherit properties from the Parent product defined in the field
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 “families” of products through Product Inheritance. This allows for derivati
ve of a product to be defined by specifying a “parent” product and different c
onditions.
Inheritance Only products do not undergo full proofing validations nor are they
available for sale. 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.

T3TAAD - R18 313
AA.PRODUCT.DESIGNER 31
4
314
 Product Currency
 Currencies in which the product is available to be indicated through multi value field
 Currency related product conditions should be available for each of the Product
currencies
 Calculation related features

 Some properties may require calculations for them
Interest and charges may be calculated as percentage of a specified balance

 User to define source balance and source property for calculation
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 and SOURCE.PROPERTY fields.
The property stated here would be validated in the proofing stage to verify if
they actually belong to this product.

T3TAAD - R18 314
Workshop– Creation of New Product 31
5
315
 Use Admin Menu > Product Builder > Products > Product Lines – Deposits
> Product Groups
Create a Product in USD under Product Group created in previous Workshop and set it
as default product
PROPERTY PRODUCT CONDITIONS ARR.LINK
ACCOUNT FIXED.DEPOSIT.BOND NON TRACKING
ACCOUNTING DEPOSITS TRACKING
ACTIVITY.MAPPING DEPOSITS TRACKING
CUSTOMER NEGOTIABLE NON TRACKING
PR.DEPOSIT USER CREATED TRACKING
COMMITMENT USER CREATED NON TRACKING
SCHEDULE USER CREATED NON TRACKING
CLOSURE USER CREATED TRACKING
PO.WITHDRAWAL USER CREATED TRACKING
DEPOSITINT USER CREATED NON TRACKING
PRESENTATION DEPOSITS TRACKING
DEPADMINFEE USER CREATED FIXED CHAR TRACKING
OFFICERS USER CREATED TRACKING
SETTLEMENT USER CREATED NON TRACKING
CHARGE.OVERRIDE MODIFY.CHARGES NON TRACKING
Calculated Property Source Type Source Balance

DEPOSITINT CR.DAILY CURACCOUNT
Creation of New Product

T3TAAD - R18 315
6
316
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

T3TAAD - R18 316
7
317
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

T3TAAD - R18 317
Proofing and Publishing 31
8
318
 Building a Product in AA is a three stage process
Designing
Proofing
Publishing
 In the design stage, the designers make use of available components to design – their actions have
no effect on live products
 To make a new product available to operational staff, it needs to be made available in Product
Catalog
The designer must Proof the product to check that there are no errors in the design (particularly
where hierarchies are involved)
It should then be duly published to be included in Catalog
 Proofing and publishing will perform processing from parent down to all children
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
synchrony 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.

T3TAAD - R18 318
Proofing and Publishing Products 31
9
319
Product Management
Proof
Create Product Proofed Publish Product
Designer Products Catalog
Fix
Modify
Product design Operations
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 checks 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 from 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.

T3TAAD - R18 319
Effective dates 32
0
320
 Available Date
The date from which the current product is available

System starts looking for valid conditions for all Properties from this date onwards

 Expiry Date
The date from which this Product ceases to exist

It only means that new Arrangements may not be input from this date for the Product

Existing Arrangements under the Product will continue


 Errors and Suggestions

When proofing fails, errors are listed out

System provides suggestions for rectification of these errors


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 displays the errors when Proofing fails.
SUGGESTION Field displays suggestions for rectifications of errors.

T3TAAD - R18 320
Workshop – Proof and Publish the Product 32
1
321
 Use Admin Menu > Product Builder > Products > Product Lines – Deposits >
Product Groups > Products
 Proof the Product created in the previous workshop with :
a) Available date as today

b) Online/service as online
 Then Publish and commit the record
Proof and Publish the Product

T3TAAD - R18 321
2
322
In this workshop, we are going to Proof and Publish the product created

T3TAAD - R18 322
Workshop – Creation of New Arrangement 32
3
323
 Use User Menu > Retail Operations > Product Catalog > Product Groups > Your
Product Group > Your Product
 Create an Arrangement for your Customer for the Product published in previous
Workshop
 Look at the PAYMENT.SCHEDULE property.
 Commit the Arrangement
 See and accept the overrides
 Get the record authorised
Create a New Arrangement

T3TAAD - R18 323
Workshop 324
324
In this workshop, we are going to create the arrangement for the product
published in the previous workshop in USD for your Customer

T3TAAD - R18 324
Workshop 32
5
325

T3TAAD - R18 325
Workshop 32
6
326

T3TAAD - R18 326
Financial Activities 32
7
327
 Payments from and into an AA Account can be done through ACCOUNT related applications
 Activity is selected based on Transaction Code
Teller Deposit Funding
Funds Transfer ACTIVITY Apply Repayment

MAPPING
Account related
Deposit Payout
Applications
When you run a transaction against an Arrangement, system automatically

invokes the appropriate Activity for that transaction.
All T24 financial transactions work with Arrangements. This happens through a
mapping between the T24 transactions and the AA Activities. Depending on the
transaction code you enter, it will know which AA activity you intend to run.

T3TAAD - R18 327
Quiz 5 – Choose the correct Answer 32
8
328
Quiz 1. How are activities auto generated ?

a) When a property is used for the first time in a Product Line
b) When a property is used for first time in a product line with
REBUILD.ACTIVITIES set to YES in AA.PRODUCT.GROUP
c) When a new Product Group is created
d) When a new Property is used in a AA.PRODUCT.DESIGNER
2. Which of the following is not an Activity in an Arrangement ?

a) Increasing commitment amount
b) Interest accrual
c) Enquiry
d) Crediting Arrangement

T3TAAD - R18 328
Quiz 5 – Choose the correct Answer 32
9
329
Quiz 3. Negotiation Rule for an attribute is FIX.VALUE. What will be the impact when the
Arrangement Link for this is set to CUSTOM.TRACKING ?
a) Will track the attribute value irrespective of Negotiation Rule.
b) Will not track the attribute value
c) FIX.VALUE cannot be negotiated but will be tracked
d) CUSTOM.TRACKING will not allow negotiation
4. How can you set allowed Currency in AA.PRODUCT.DESIGNER?

a) Option ‘ALL’ in CURRENCY Field will allow all currencies
b) Restricted Currencies can be specified in CURRENCY Field to allow all other
currencies
c) Allowed Currencies to be input in the multi value ‘CURRENCY’ Field
d) A Product can be set only for Local Currency

T3TAAD - R18 329
33
0
330
 Simulation

T3TAAD - R18 330
Simulation - Overview 33
1
331
 Simulation replicates real time scenario

 For a new or existing arrangement for a set of conditions
 Repayment amounts for changes in principal, interest rate, tenor, charges, Pay out amount for closure of
arrangement on a specific date
 Simulation does regular updates as if a real activity but stores data in simulated files
 Checks conditions and negotiation rules, generates override and error messages
 Calculates maturity date, charges, repayment amounts
 Prepares repayment schedule
 Simulated data are not real and the projected data are stored in SIM files
 Live arrangement will not be created or updated
 Option to convert simulation activity into live
AA provides a Simulation tool which can help in decision making for the
customer.
• Creates simulation for prospective and existing customers. Can perform what-
if speculation for new deposits. When running a simulation for a NEW
Arrangement, the Related Activity field has to be set to DEPOSITS-
APPLY.PAYMENT-COMMITMENT in the New Arrangement Activity to
enable view of Payment schedule in the simulated Arrangement Overview.
•Can View payment schedule for simulated deposits.
• Convert simulated deposit into a live deposit.
• What would be the result of a future dated activity on an existing arrangement.
When an activity is simulated, system actually performs all actions but stores
these details in a separate simulated file. Enquiries can be written to process data
in these files to provide user interface.

T3TAAD - R18 331
Simulation - Process 33
2
332
 Can be run for various combinations of projected activities

Run on the current or a future date
For a defined period of time
 With a start date and end date
 Multiple simulations can be run for a single arrangement

More than one activity can be simulated in a single run
 Change of term, change of principal and change of interest rate
 Arrangement under any AA product can be simulated
 Simulated activity can be retained for a specified period
AA Simulation can be run for future dated activities. We can simulate a set of
activities for a specific period.
More than one activity can be simulated simultaneously.
Simulation can be run for any AA Product. Simulation performs activities
without creating or updating live records and produces output for these
activities. This helps customer to take decision to opt for arrangements.
Simulated activities can be retained for a user defined days and customer and if
customer opts, then it can be executed into live records. Simulation also
performs activities on existing arrangements for situations like what if paid out,
partial repayment, renewed on a specified date etc.

T3TAAD - R18 332
Simulation – Sub Systems 33
3
333
 Simulation data capture

 Capture data for simulation of new arrangement
 Capture data as part of simulating activities for live arrangement
 Renewal, payout calculation for existing deposits
 Simulation runner
 For a specified period
 For specified set of activities
 Simulation Service
 Run simulation for the captured data with the help of service
 Run TSA.SERVICE agent and BNK/AA.SIMULATION.SERVICE
This stores required data in different files for retrieval later
Simulation within AA would require sub-systems. They are Simulation data

capture and Simulation Runner.
Simulation data capture captures data for activity being simulated, subject to
negotiation conditions of the product.
Simulation runner is used to define the period of simulation and list of activities
to be simulated. On authorisation, it generates OFS message which is picked by
AA.SIMULATION.SERVICE. This runner, runs the data captured through the
Simulation data capture, the results of which can be viewed through the
simulated Arrangement Overview.

T3TAAD - R18 333
Quiz 6– Choose the correct Answer 33
4
334
Quiz What is Simulation in AA ?

1.
a) Process of payout of AA Deposit

b) Process of replicating a real time scenario
c) Process of closing an Arrangement
d) Process of creating an Arrangement
Which of the following is true about Simulation in AA ?

2.
a) It does real activity and updates / creates live records

b) Simulated records cannot be executed into live records
c) It does real activity but will not update / create live records
d) Simulation is possible only for existing arrangements

T3TAAD - R18 334
Pre-requisite for Simulation workshops 33
5
335
 Use Command Line > TSA.SERVICE,

 Set BNK/AA.SIMULATION.SERVICE to START
 Set TSM to START
 Run the SERVICE
 Log in to Putty
 Type START.TSM –DEBUG
 Check tSA ‘**’ number for BNK/AA/SIMULATION.SERVICE
 If the agents are already running, type –CLEAR.FILE F.TSA.STATUS
 Log in to another putty session

 Type tSA **
 BNK/AA/SIMULATION.SERVICE is manually launched
Prerequisite for Simulation Workshop

T3TAAD - R18 335
Workshop – Simulation of an Arrangement 33
6
336
 Use User Menu > Product Catalog > Product Groups > Term Deposits > 3 Months
Deposit
Simulate an arrangement for your customer effective today

Deposit amount USD 1,00,000


Commit the record


 Use User Menu > Retail Operations > Find Deposits > New Offers
Open your simulated arrangement, view arrangement conditions and Schedule

Convert the simulated arrangement to a live one through ‘Execute’


 Use User Menu > Retail Operations > Find Deposits > Authorised
View the live arrangement and authorised

Create a Simulated arrange and Convert the simulated arrangement to a live one
through ‘Execute’

T3TAAD - R18 336
7
337
In this workshop , we are going to create a Simulated arrangement

Simulate an arrangement for your customer effective today

T3TAAD - R18 337
8
338
In this workshop , we are going to create a Simulated arrangement

• Deposit amount USD 1,00,000
• Commit the record

T3TAAD - R18 338
9
339
Check the Simulation Status – If it is Completed Successfully

View the Simulated Arrangement Overview
Convert the simulated arrangement to a live one through ‘Execute’

T3TAAD - R18 339
0
340
Check the Simulation Status – Executed Successfully

View the Live Arrangement

T3TAAD - R18 340
1
341
View the live arrangement Overview, Financial Summary and Activity Log

T3TAAD - R18 341
Workshop– Deposit Funding 34
2
342
 Use User Menu > Retail Operations > Deposit Transactions > Arrangement
Activities (FT) > AA Deposit - Fund
 Select the arrangement opened in the previous workshop
 Deposit USD 100,000
 Approve Overrides
 Get the record authorised
 View the activity log, financial summary and payment schedule of deposit
arrangement
Fund the Deposit Arrangement

T3TAAD - R18 342
3
343
In this workshop we are going to Fund the Deposit Arrangement created

• Deposit USD 100000 to the Arrangement opened in the Previous
Workshop
• Approve Overrides
• Get the record authorised

T3TAAD - R18 343
4
344
View the Arrangement Overview, Financial Summary, Activity Log and

Payment Schedule.

T3TAAD - R18 344
Workshop– Customer Change 34
5
345
 Use User Menu > Retail Operations > Find Deposits

 Select an Arrangement record of your customer created earlier and add an existing
customer to the arrangement as joint customer
Addition of joint customer to current arrangement

T3TAAD - R18 345
6
346
In this workshop, we are going to select the existing arrangement created and
add a joint customer by selecting the New Activity Tab and the CHANGE
CUSTOMER ACTIVITY FOR CUSTOMER

T3TAAD - R18 346
7
347
Addition of joint customer to current arrangement

T3TAAD - R18 347
Workshop - Creation of Securities Portfolio 34
8
348
 Use User Menu > Private Operations > Securities>Front Office>Client

Maintenance>Private Customer>Private Customer>Customer Security
• Include individual customer created earlier as an investor of securities
 Use User Menu > Private Operations > Securities>Front Office>Client

Maintenance>Private Customer>Private Customer>Securities Portfolio
Create the portfolio for your customer as under
Currency : USD
Choose any desired values for Portfolio Program and Management Account from the
dropdown list
Use a suitable account name for the portfolio
Use USD account of your customer as Account No. and Safekeeping Account
Creation of CUSTOMER.SECURITY and SEC.ACC.MASTER

T3TAAD - R18 348
9
349
In this workshop, we are going to create CUSTOMER.SECURITY and

SECURITY PORTFOLIO for your customer
Include individual customer created earlier as an investor of
securities
• Currency : USD
• Choose any desired values for Portfolio Program and
Management Account from the dropdown list
• Use a suitable account name for the portfolio
• Use USD account of your customer as Account No. and
Safekeeping Account

T3TAAD - R18 349
Workshop - ENQ SC.VAL.COST 35
0
350
 Use User Menu > Product Catalog > Deposit >Term Deposits > Long Term
Deposit
 Input an Arrangement for USD 300,000 for your individual customer
 Now mention the Portfolio ID created for the customer in the Portfolio ID of the
Account property in the Arrangement
 Commit and accept overrides, if any
 Get the record authorised.
 Go to the Command line and type ENQ SC.VAL.COST and key in the Portfolio
ID mentioned in the Arrangement and view the Deposit Arrangement included
in your portfolio.
Create an Arrangement and attach the PORTFOLIO.ID in the Arrangement of

the customer and view the Deposit Arrangement included in that PORTFOLIO
through ENQ SC.VAL.COST

T3TAAD - R18 350
1
351
In this workshop, we are going to create an arrangement to attach the

PORTFOLIO ID created in to the Deposit Arrangement
Input an Arrangement for USD 300,000 for your individual customer
Now mention the Portfolio ID created for the customer in the Portfolio
ID of the Account property in the Arrangement
Commit and accept overrides, if any
Get the record authorised.

T3TAAD - R18 351
2
352
Go to the Command line and type ENQ SC.VAL.COST and key in the Portfolio
ID mentioned in the Arrangement and view the Deposit Arrangement included
in your portfolio.

T3TAAD - R18 352
Workshop 35
3
353
 Select a Deposit arrangement
 Input a fully negotiable loan inline with the Linked arrangement as Deposit
arrangement with a margin on the deposit interest
 View the arrangements for the tracking information updated.
Select a Deposit arrangement

Input a fully negotiable loan inline with the Linked arrangement as Deposit
arrangement with a margin on the deposit interest
View the arrangements for the tracking information updated.

T3TAAD - R18 353
4
354
Select a Deposit arrangement from list the deposits that is funded and current
status.

T3TAAD - R18 354
5
355
Create a fully negotiable loan with amount similar to the deposit arrangement.

T3TAAD - R18 355
6
356
Set up the principal interest linked to the deposit arrangement using fields :
Spread set to YES, Linked Arrangement and Linked property
In this case the margin of 0.5 is added on top of the deposit interest for the loan
arrangement.
The loan is setup for auto disbursal and settlement account is setup only for
disbursement in this case.

T3TAAD - R18 356
7
357
Upon authorisation we can find the loan arrangement contains the information
of the deposit arrangement as tracked for interest rate
The deposit arrangement contains the information of the arrangement that has
tracked rates and used this as source arrangement.

T3TAAD - R18 357
8
358
Select a Deposit arrangement from list the deposits that is funded and current
status.

T3TAAD - R18 358
Statements / Passbooks 35
9
359
 Customer statements possible to be issued for arrangements

 Statement setup can be configured through Statement property class
 Statement entries updated with narratives from transaction code of the transaction triggered
through an Arrangement activity
 AC.POSTING.DETAILS is used for narrative updates in stmt entries

 Appropriate narrative activity-wise essential
 ENTRY.VALUE multi-value field set with PROPERTY, ACTIVITY etc
 VALUE.SOURCE field to be set as EVENT
 In AA.ARRANGEMENT.ACTIVITY, Field NARRATIVE can be used for further description for the
triggered activity
 Used mainly for adhoc charges
It is possible to issue Customer statements / passbooks for arrangements

Statement setup can be configured through Statement property class. Please
refer to ELearning Statement property class for further details.
The statement entries raised for the Arrangements are updated with the
Narratives from the Transaction code of the transaction which is triggered
through the Arrangement Activity. When Accounting entries are raised for an
AA Account, Soft Accounting picks up the description from the
TRANSACTION table and maps them to narrative. Narrative updations in
statement entries for Arrangements are handled by Soft Accounting with the
help of setup done in AC.POSTING.DETAILS file. To get the appropriate
narrative description, ENTRY.VALUE multi-value field in the
AC.POSTING.DETAIL file to be set with the options like PROPERTY,
ACTIVITY, and ARRANGEMENT.ACTIVITY. Based on these options, the
Narratives in the Accounting entries will be updated with the Property / Activity
/ Arrangement Activity names and their descriptions. To achieve the same the
VALUE.SOURCE field should be set as EVENT.
A new field NARRATIVE is introduced in the AA Arrangement Activity table
(AAA) to write further description for the triggered activity. It would be used
mainly for Ad hoc Charges. This narrative is in addition to the Property

T3TAAD - R18 359
description.
This gives a clear picture of the purpose of the Activity and also helps the end user as
well as the Bank to identify/consolidate the same.

T3TAAD - R18 359
Masking of entries in Statements / Passbooks 36
0
360
 Customer statements based on Account movements (STMT.ENTRY) generated for that

arrangement
 Possible to mask a set of Statement entries from enquiry / printing

 MASK.PRINT flag in STMT.ENTRY record to be set as Yes
 Entries generated to make Payments due will continue, but these will not appear in
Customer statement
 Accounting movements to move balances from one balance type to another
E.g. CUR to DUE, DUE to GRA
 Field MASK in AC.ALLOCATION.RULE set as Yes for Mvmt & Target entries if mask print flag
is required
AA generates accounting movements to move from one balance to another (e.g.

to move from the current balance to the due balance on a repayment date). From
an accounting perspective these movements are confusing to a customer, hence
need to be masked in statements / passbooks.
Possible to mask a set of Stmt entries from Enquiry or Statement printing, if
flag MASK.PRINT is set in the Stmt.Entry record.
The entries generated to make Payments due will not be changed, but these
entries will not appear in the Customer statement.
AC.ALLOCATION.RULE is used to identify which set of entries should be
masked for Statement printing: Field MASK, if set to ‘YES’ for both the Mvmt
& Target entries (default is blank), system then sets the MASK.PRINT flag in
the STMT.ENTRY. This is a part of the multi-value fields associated with
Event.Type in AC.ALLOCATION.RULE.
Although the internal entries will be generated, they will not appear in the
Customer statement or related enquiry.

T3TAAD - R18 360
Enquiries 36
1
361
 Built in enquiries within Arrangement record
Balance - Commitment amount, Current principal, pending charges, unspecified credit, unspecified
debits, etc
Activity log
 Displays all activities executed in date and sequence

 Provides the user to view Activity Details by Financial, User Initiated,
 System Initiated and Future Activities
Provides access to the Arrangement Activity record to view activity details
Basis for reverse and replay processing and shows corrected activities
Bills
Due date, activity type, bill amount, outstanding, status - whether due or settled, Days
past due (DPD)
Enquiries on AA Arrangements are part of every Arrangement record.

Balance Enquiry will display the commitment amount, current principal,
charges due, unspecified credits, etc.
Activity Log (AA.ACTIVITY.HISTORY) will display all Activities that have
been executed for an Arrangement in date and sequence order; provides access
to the Arrangement Activity record to view the Activity details and the
Arrangement Conditions at the point when the Activity was launched.
Each Activity performed on an arrangement is effective dated and stored in T24
in the sequence of activities, with links to financial transactions (e.g. deposits,
redemptions, repayments, etc.) as to when it was performed, how many times it
was performed etc.
The users can view multiple versions of the activity viz Financial, User Initiated,
System Initiated and Future activities. Future activities will be shown in the
same logs but will have their date in a different format (e.g. italics) to note that
the activity has not yet taken place
Activities like accruals with NOLOG attributes are not recorded in
AA.ACTIVITY.HISTORY.
Bills enquiry is used to view due dates of bills, activity type, amount, whether
paid or not status, Days past due (DPD) ie: Number of days by which each bill
has moved to the Overdue status

T3TAAD - R18 361
Enquiries 36
2
362
 Built in enquiries within Arrangement record

 Charges
• By Date – Enquiry by payment date
• By Type – Enquiry by charge property
 Messages
 Messages relating to activities
 Payment Schedule
 Scheduled date, amount, outstanding principal, interest and total etc
 Account Details
 Maturity date depending on term
Charges enquiry can be viewed by payment date (By Date) and by Charge
property (By Type). It displays the charges enquiry by payment date, type,
default amount, waived amount if any, final amount and the outstanding amount.
Associated Messages for activities are generated in AA. These messages could
be viewed through Messages Enquiry. Further drilling down will display the
full details of the message.
Payment Schedule generated based on product conditions could be seen under
this enquiry.
Interest details enquiry will display the interest details, such as interest
scheduled date, interest rate, interest days, amount of interest and principal on
which interest is calculated, tax calculated at source on Interest etc.
The Arrangement Overview screen under the section “Account Details” shows a
“Maturity Date” if Null has not been specified at the arrangement level. The
“Renewal Date” is still shown as a theoretical maturity date as determined by
the values in change product.

T3TAAD - R18 362
Workshop 36
3
363
 Use User Menu > Retail Operations > Find Deposits > Authorised Arrangements
 Select an existing arrangement
 Look at the following through the respective enquiry tabs
 Balances
Activity Log, drill down to view an activity and view the full, financial, user
Initiated and system initiated activities
 Bills and drill down a bill to look into the details
 Payment Schedule and open two records and see the contents
Arrangement Enquiries

T3TAAD - R18 363
4
364
In this workshop, we are going to select the existing arrangement created and
view the Balances

T3TAAD - R18 364
5
365
Activity Log, drill down to view an activity

T3TAAD - R18 365
6
366
View the activity log

T3TAAD - R18 366
7
367
Bills and drill down a bill to look into the details

T3TAAD - R18 367
8
368
Payment Schedule and open two records and see the contents

T3TAAD - R18 368
9
369
 Features of Lending
 Building Banking Products and create

Lending arrangements

T3TAAD - R18 369
37
0
370
Savings Plan - Product Overview

T3TAAD - R18 370
1
371
 Savings Plan Product

T3TAAD - R18 371
AA Savings Plan – Product Overview 37
2
372
Regular / Bonus
missed within
tolerance
Periodic Fixed
Savings Plan amount
Missed
payments No Bonus
above
tolerance
A savings plan is similar to a recurring deposit. It is an agreement by the

customer to pay a specific amount of money on a periodic basis. A customer
can take out the following type of savings plan:
The commitment plan, requires the customer to commit to saving a specific
amount of money on a periodic basis. In return for adhering to the payment
schedule in the plan, the client receives a bonus payment. Though this involves
payment of a fixed amount on a periodic basis, this type of savings deposit may
or may not have a term. At the end of the committed period a bonus may be paid
if certain criteria e.g. number of missed receipts is below the agreed number.
The bonus (a payable charge) is conditional on:
There being no late payments during the term of the savings plan OR
The number of missed payments is less than a pre-defined tolerance.
The average delinquency AMOUNT for a status is less than x.
The total days in a delinquency status is less than x.
The bonus is generally payable to the customer on the maturity date of the
Savings Plan.

T3TAAD - R18 372
Bonus processing - features 37
3
373
 Pay-out of Bonus
• A payable charge
• Can be a fixed amount / calculated amount / routine based amount
 Payable on maturity date or at a periodic frequency
 Eligibility of bonus can be determined based on:

 There being no late payments during the term of the savings plan
 Number of missed payments being less than pre-defined tolerance
 Average delinquency AMOUNT for a status is less than x
 Total days in a delinquency status is less than x
 Credit for payment of bonus indicated through charge property
Pay-out of Bonus will be a payable charge, It can be a fixed amount / calculated

amount / routine based amount. Bonus is Payable on maturity date or at a
periodic frequency.
Eligibility of bonus can be determined based on:
 There being no late payments during the term of the savings plan
 Number of missed payments being less than pre-defined tolerance
 Average delinquency AMOUNT for a status is less than x
 Total days in a delinquency status is less than x
Credit for payment of bonus indicated through charge property.

T3TAAD - R18 373
Bonus – Credit charge property 37
4
374
 Credit for payment of bonus indicated through charge property
While defining the charge property, Type field needs to be indicated as ‘Credit’
if the charge is payable by the Bank

T3TAAD - R18 374
Payment schedule with respect to Savings Plan 37
5
375
 Commitment from customer to pay a specific amount of money on a periodic

basis
 Notional payments defined in Payment Schedule property as Expected
 Interest and Bonus are both payable
 Minimum commitment savings amount and maximum are defined under

Negotiation rules tab
In the Payment schedule, Commitment from customer to pay a specific amount

of money on a periodic basis is indicated. These are shown as notional expected
payments. Interest and bonus are payable properties.
Minimum commitment savings amount and maximum are defined under
Negotiation rules tab

T3TAAD - R18 375
Payment Schedule for Savings Plan 376
376
Notional payments expected are defined in Account property with monthly

frequency.
Interest is payable after a year. Bonus is payable on maturity.
Committed savings amount should be a minimum of 500 (can be less with the
acceptance of an Override) and exceeding 500 should be in multiples of 100.

T3TAAD - R18 376
Term amount with respect to Savings Plan 37
7
377
 Term can be defaulted and negotiated at arrangement level

 Pertains to the term of commitment savings
• If an amount is input, considered as the initial deposit

• Term amount may be left blank
• Commitment amount specified in field ACTUAL.AMT in Payment Schedule
• Permitted terms can be indicated under negotiation tab to include the various
values
• Cooling period and Cancel period fields applicable for Savings plan
•Term can be defaulted and negotiated at arrangement level, indicates term of

commitment savings. If an amount is input, considered as the initial deposit.
Term amount may be left blank, Commitment amount specified in field
ACTUAL.AMT in Payment Schedule. Permitted terms can be indicated under
negotiation tab to include the various values. Cooling period and Cancel period
fields are applicable for Savings plan as well.

T3TAAD - R18 377
Term amount for Savings Plan 37
8
378
Term Amount Condition setup:

1. Default Values : Amount :500, Term :24M, Colling Period: 1M and Cancel
Period: 7D.
2. Negotiation Rules: Amount Minimum is 500 with override and Multiples of
100 with error, Term can be 12M or 18M or 24M or 36M or 48M or 60M only.

T3TAAD - R18 378
Activity Restriction product condition 37
9
379
 Evaluation of bonus eligibility done through Activity Restriction
 The activity to asses eligibility rule pertains to Overdue (Grace)
 On evaluation, if rule is broken, bonus is waived
 Periodic attribute used to indicate the period of rule eligibility
Evaluation of bonus eligibility done through Activity

Restriction
The activity to asses eligibility rule pertains to

Overdue (Grace)
On evaluation, if rule is broken, bonus is waived
Periodic attribute used to indicate the period of rule

eligibility

T3TAAD - R18 379
Activity Restriction with respect to Savings Plan 38
0
380
Set up of Activity Restriction to asses eligibility rule pertains to Overdue

(Grace). On evaluation, if rule is broken, bonus is waived

T3TAAD - R18 380
Overdue with respect to Savings Plan 38
1
381
 Overdue property used to age Expected bills and record missed payments
 Ability to age any type of bill
 Separate aging rules based on type of overdue amount
 BILL.TYPE
 Can be specified for individual Overdue status
Obtains default values from AA.BILL.TYPE virtual table

•
Overdue property used to age Expected bills and record missed payments.
Possible to age any type of bill. Separate aging rules based on type of overdue
amount can be defined. BILL.TYPE can be specified for individual Overdue
status, default values obtained from AA.BILL.TYPE virtual table

T3TAAD - R18 381
Overdue product condition 38
2
382
Overdue Condition setup: Bill type : Expected, Overdue status: Grace and
Aging days: 5.

T3TAAD - R18 382
38
3
383
Savings Plan Periodic Attributes

T3TAAD - R18 383
Periodic attributes related to Savings Plan 38
4
384
 MAXIMUM.DELINQUENT.AMOUNT
Delinquency amount in expected dues
•
Overdue amount for aging activity over a period

•
 MAXIMUM.DELINQUENT.DAYS
Total days in a delinquency status for defaulted expected dues
•
Overdue days for aging activity over a period

•
• Both periodic attributes used to reckon default payments in amounts / days
When a rule is to be setup based on overdue amount for aging activity over a
period – MAXIMUM.DELINQUENT.AMOUNT to be used
When a rule is to be setup based on overdue days for aging activity over a
period – MAXIMUM.DELINQUENT.DAYS to be used

T3TAAD - R18 384
38
5
385
Configuring a Savings Plan Product

T3TAAD - R18 385
Demo Configuring a Savings Plan Product 38
6
386
Use Admin Menu > Product Builder > Products > Deposits > Product Groups > Product
Property Product Condition ARR Link
ACCOUNT COMMITMENT.SAVINGS Non Tracking
ACCOUNTING DEPOSITS Tracking
ACTIVITY.MAPPING DEPOSITS Tracking
PRESENTATION DEPOSITS.SAVINGS Tracking
ARRANGEMENT.RULES COMMITMENT.SAVINGS Non Tracking
BALANCE.MAINTENANCE NEGOTIABLE Non Tracking
ADMINFEE 250 Non Tracking
REDEMPTIONFEE 100 Non Tracking
BONUS PERCENTAGE.2 Non Tracking
CHARGE.OVERRIDE MODIFY.CHARGES Non Tracking
CLOSURE 3D.AFTER.ZERO.BALANCE Tracking
CUSTOMER NEGOTIABLE Non Tracking
DEPOSITINT AD.PERIODIC Non Tracking
PR.DEPOSIT ALLOCATE.DEPOSIT Tracking
AD.CAP.INTEREST.YEARLY+DEPOSIT.MON
SCHEDULE Non Tracking
THLY
PO.EARLY.WITHDRAWAL CURRENT.BALANCES Tracking
PO.WITHDRAWAL PAY.BALANCES Tracking
SETTLEMENT DEPOSITS Non Tracking
COMMITMENT COMMITMENT.SAVINGS Non Tracking
OVERDUE DEPOSIT.BONUS Tracking
Under the savings plan group let us create a product for savings plan

T3TAAD - R18 386
Demo 46 - Configuring a Savings Plan Product
Workshop
38
7
387
Calc. Property Source Type Source Balance

DEPOSITINT CR.DAILY CURBALANCE
REDEMPTIONFEE TXN.AMOUNT
BONUS CR.DAILY CURBALANCE
Note: Verify the COMMITMENT.SAVINGS product condition of Account record and ensure the
Passbook field is setup as “No”
Ensure Payment Schedule and Settlement product condition match
Note: Verify the COMMITMENT.SAVINGS product condition of Account

record and ensure the Passbook field is setup as “No”
Ensure Payment Schedule and Settlement product condition match

T3TAAD - R18 387
Demo - Configuring a Savings Plan Product
Solution
38
8
388
The product condition of account and payment schedule is checked up here.

T3TAAD - R18 388
38
Demo 9
389
The settlement product condition is verified and it is ensured to be inline with

payment schedule
Pay in settle activity : DEPOSITS-APPLYPAYMENT-PR.DEPOSIT

T3TAAD - R18 389
39
Demo - Configuring a Savings Plan Product 0
390
The product designer screen is seen here

T3TAAD - R18 390
39
391
The product designer is seen here.

T3TAAD - R18 391
2
392

T3TAAD - R18 392
39
Creating a Savings Plan arrangement 3
393
Arrangement is created under the product after proofing and publishing the same
Initial commitment amount is 500 (Term amount)

T3TAAD - R18 393
39
394
Regular commitment amount expected is 100 (Payment Schedule),
Check Pay in and Pay out rules.

T3TAAD - R18 394
39
395
Arrangement is created and the same is seen here.

T3TAAD - R18 395
Funding the Savings Plan arrangement 396
396
Funding the initial commitment amount of 500

T3TAAD - R18 396
39
Viewing the Savings Plan arrangement 7
397
Viewing the Arrangement Overview

And expected bill is settled.

T3TAAD - R18 397
8
398
Quiz
1. Payment of bonus indicated through charge property with
Credit type
a) True
b) False

T3TAAD - R18 398
9
399
 Savings Plan Product

T3TAAD - R18 399
400
400
Customer Segment Pricing –

Channel Pricing

T3TAAD - R18 400
1
401
 Customer segment pricing

T3TAAD - R18 401
Customer Segment Pricing Slide 402
402
Based on segmenting customers into groups and determining the profitability

of the customer
A customer segmentation allows
 Drive sales force behavior strategically
 Increase the overall profitability
 Sustainability of the business by creating a customer hierarchy and focusing

on specific groups
Based on segmenting customers into groups and determining the profitability of

the customer
A customer segmentation allows you to drive sales force behavior strategically

and increase the overall profitability and sustainability of the business by
creating a customer hierarchy and focusing on specific groups.

T3TAAD - R18 402
Channel Pricing Slide 403
403
 Channel Pricing is a strategy for Product variation.
 Version of an existing product with a different pricing
 Restricts the channels used by customer
E.g.: Internet only products.
 Channel Pricing differs from Relationship Pricing
 Relationship pricing can be applicable to all or some or no product variants
Channel Pricing is a strategy for Product variation.

It allows financial institutions to offer a version of an existing product with a
different pricing by restricting the channels that a customer can use to maintain
or transact with their account.
The most common example of this is Internet only products.
The requirements for Channel Pricing differ from Relationship Pricing, as the
pricing normally depends on which channel the customer chooses to use for a
particular product rather than a customer’s relationship with the bank.
Remember: It is possible to define that relationship pricing is applicable to all,
only some or no product variants.

T3TAAD - R18 403
Preferential Pricing Slide 404
404
 Preferential pricing offers clients better prices or rates on all or part of their
business.
 E.g.: a higher rate on Deposits or a lower interest rate on loans, if the client uses more
of its products or services.
 Preferential pricing refers to the use of any of the available methods

 Product Variations
 Relationship Pricing
 Promotional Pricing
Preferential pricing offers clients better prices or rates on all or part of their
business. For example, a bank could offer a client preferential pricing – a higher
rate on Deposits or a lower interest rate on loans, if the client uses more of its
products or services.
Preferential pricing refers to the use of any of the available methods (i.e.
Product Variations, Relationship Pricing and Promotional Pricing) to provide
customers with interest rates and/or charges, which are better than the standard
product.

T3TAAD - R18 404
Eligibility Property and Product Variations Slide 405
405
Product Variations – Eligibility product conditions has to be set up for each

variation.
 variations for Eligibility are indicated in multi-value fields against the property
for eligibility
 Order of priority for variation – the highest priority for the channel desired
 Property level variation – checked at proofing stage
 Default conditions should be specified is default product is required
 Channels eligibility can be marked as variation eligibility criteria.
Variations in product can be achieved based on a eligibility Check. We have

already seen that Eligibility is variation specific property class and product
condition can be defined for every variation.
Channel Pricing, Customer Segment Pricing, Preferential Pricing can be

achieved by defining eligibility criteria for the customer to get the special
features.
This can be subsidized interest or charges.
If one or more variations are specified for a particular property, the proofing
mechanism will check whether conditions for those variations exist for that
Property. If not and error will be raised.
In the case of ELIGIBILITY, all variations specified at the Product level must
exist and be specified at the Property level.
If a product has been defined as multi currency, then a currency specific
property with a variation (e.g. internet) must have that variation defined for
every currency.

T3TAAD - R18 405
Eligibility Property and Variations Slide 406
406
Evaluation on new arrangement creation
Evaluates the eligibility for each variation in priority specified
Uses the first variation for which the customer is eligible.
If the customer is not eligible for any of the variations or the default (if specified)
then the Product will not appear in the customer specific version of the Product
Catalog.
When user opens a variation manually if the eligibility criteria have been set to
raise an Override as opposed to an error.
The eligibility rules are evaluated at the Product Catalog level during new
arrangement creation.
AA evaluates the eligibility criteria of each variation (e.g. senior, staff, child) in
the priority order specified and uses the first variation for which the customer is
eligible.
If the customer is not eligible for any of the variations or the default (if
specified) then the Product will not appear in the customer specific version of
the Product Catalog.
The user can open a variation manually, if the eligibility criteria have been set to
raise an Override as opposed to an error.

T3TAAD - R18 406
Review of Eligibility on an Arrangement - Variations Slide 407
407
Review of eligibility - triggered by either a static change or on periodic basis
Eligibility check of
customer of each
variation
Neither eligible for

If needed to
If eligible for upgrade Eligible for current variation nor for
downgrade - “
- “Change Variation” product but not for default product –
Change Variation”
activity (“reset”) upgrade – no action change to product
activity (“reset”)
without eligibility
When triggered by either a static change or on a period (depending on the

condition of the currently applicable eligibility) the system will again check the
eligibility of each variation in order to determine which one the customer is best
suited for.
If they are eligible for a higher priority variation (i.e. an upgrade) then AA will
trigger a “Change Variation” activity namely : ACCOUNTS-
CHANGE.VARIATION-ARRANGEMENT, DEPOSITS-
CHANGE.VARIATION-ARRANGEMENT, LENDING-
CHANGE.VARIATION-ARRANGEMENT, RELATIONSHIP.PRICING-
CHANGE.VARIATION-ARRANGEMENT
and the conditions will change based upon the “reset” setting of each property.
If they are not eligible for an upgrade but they are still eligible for the current
variation then no further action is required.
If they need to be downgraded then AA will trigger a “Change Variation”
activity to downgrade their conditions based upon the “reset” settings.
Finally, if they are not available for any variation or the default, then for
financial arrangements AA will follow the existing rules that will change the
product itself to a specified product without eligibility rules. In the case of a
Relationship Pricing arrangement a new option (described later) will
automatically close the arrangement.

T3TAAD - R18 407
Workshop – Variation setup and Interest rates for variation Slide 408
408
View the rules in EB.RULES.VERSION for staff customers and resident

customers.
Create two new variations STAFF and FOREIGNER in EB.LOOKUP
 Use Admin Menu > Product Builder > Product Conditions > INTEREST
 Create Interest product condition in USD currency for
 Staff variation created – fixed rate of 7%

 Foreigner variation created – fixed rate of 6.75%
 No variation – fixed rate of 6%
 Indicate a tier type as single and Accrual Rule as FIRST along with Interest
day basis “B”
 Attributes are negotiable by default
View the rules in EB.RULES.VERSION for staff

customers and resident customers.
Create two new variations STAFF and
FOREIGNER in EB.LOOKUP
 Use Admin Menu > Product Builder >

Product Conditions > INTEREST
 Create Interest product condition in USD
currency for

 Foreigner variation created – fixed rate of
6.75%

T3TAAD - R18 408
 Indicate a tier type as single and Accrual Rule as
FIRST along with Interest day basis “B”
 Attributes are negotiable by default

T3TAAD - R18 408
9
409
View the rules in EB.RULES.VERSION for staff customers and resident

customers.
Create variations for STAFF and FOREIGNER in EB.LOOKUP

T3TAAD - R18 409
0
410
Interest product condition in USD currency for

 Foreigner variation created – fixed rate of
6.75%

T3TAAD - R18 410
Workshop – Eligibility product condition 411
411
 Create an Eligibility product conditions record similar to earlier one.

Set up the default product as the product created earlier
Create an Eligibility product conditions record similar to earlier one.


T3TAAD - R18 411
Solution Slide 412
412
Create an Eligibility product conditions record similar to earlier one.


T3TAAD - R18 412
Workshop - Customer Segment Pricing 41
3
413
 Use Admin Menu > Product Builder > Products > Product Lines –Deposits
> Product Groups
 Create Child Product available in USD under the product earlier created
 No default product
PROPERTY PRODUCT CONDITIONS ARR LINK

PRINCIPALINT SEASONAL NONTRACKING STAFF & FOREIGNER
VARIATION
ELIGIBILITY SEASONALDEP TRACKING STAFF & FOREIGNER

VARIATION
Create a child product to the default product with two variations for interest and
eligibility for them

T3TAAD - R18 413
Solution Slide 414
414
Staff and Foreigner variation setup in product designer

T3TAAD - R18 414
Solution Slide 415
415
Proof and publish the product

T3TAAD - R18 415
Customer Segment Arrangements
Slide 416
416
 Create Arrangement under each eligibility condition

View the variations and the interest defaulted as per the variation.
List the customer records that are of the staff sector. Create an arrangement
with one of those customers and view the variation chosen by the system and
the related interest defaulted
List the customer records that are non resident. . Create an arrangement with
one of those customers and view the variation chosen by the system and the
related interest defaulted
List the customer records that are non resident and also staff sector. Create
an arrangement with one of those customers and view the variation chosen by
the system and the related interest defaulted.

T3TAAD - R18 416
Solution Slide 417
417
STAFF
List the customer records that are of the staff sector. Create an arrangement with
one of those customers and view the variation chosen by the system and the
related interest defaulted

T3TAAD - R18 417
Solution Slide 418
418
FOREIGNER
List the customer records that are non resident. Create an arrangement with one
of those customers and view the variation chosen by the system and the related
interest defaulted

T3TAAD - R18 418
Solution Slide 419
Both staff and Foreigner 419
What would happen if the customer is neither a staff nor a foreigner?
List the customer records that are non resident and also staff sector. Create an
arrangement with one of those customers and view the variation chosen by the
system and the related interest defaulted.
Would you like to list the customer that do not match any of the criteria. Create
an arrangement for the customer - view the variation and interest rate defaulted.

T3TAAD - R18 419
0
420
Quiz
1. Channel pricing cannot be achieved using Variations
a) True
b) False

T3TAAD - R18 420
1
421
 Customer segment pricing

T3TAAD - R18 421
2
422
Conclusion Introduction to Deposits Product Line and

Property Classes
Setup parameter tables, create Property

and Product conditions for Deposits
Product Line
Create Deposits Product Group and

Product, proof and publish the product
About Deposits activities, Simulation
Enquiries relevant to this module
Viewing the features of a Savings plan

product
Variation Product for Deposits

T3TAAD - R18 422
42
3
423
Thank You

T3TAAD - R18 423

T3TAAD-Arrangement Architecture Deposits

Uploaded by

Document Information

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

T3TAAD-Arrangement Architecture Deposits

Uploaded by

Copyright:

Available Formats

1

T24 Arrangement Architecture -Deposits -

Copyright © 2010 - Present- Temenos Headquarters S.A. All rights reserved.

T24 Arrangement Architecture -Deposits -

Objectives • Introduction to Deposits Product Line

• Setup parameter tables, create Property

• Create Deposits Product Group and

• About Deposits activities, Simulation

• Enquiries relevant to this module

• Viewing the features of a Savings plan

• Variation Product for Deposits

T24 Arrangement Architecture -Deposits -

Overview – Retail Deposits

T24 Arrangement Architecture -Deposits -

Objectives  In this learning unit let us have a

 Basic overview of AA Deposits

 Quick recap of property class type and

T24 Arrangement Architecture -Deposits -

Arrangement is an agreement between the bank and interested party to provide

T24 Arrangement Architecture -Deposits -

T24 Arrangement Architecture -Deposits -

T24 Arrangement Architecture -Deposits -

 AA also uses other Static tables

AA uses the following T24 functionalities namely Customer records to refer a

T24 Arrangement Architecture -Deposits -

BASIC.INTEREST Table is used for applying floating interest in an

T24 Arrangement Architecture -Deposits -

Bid rate is used 10

T24 Arrangement Architecture -Deposits -

Possible to indicate Countries and Regions in BUS.DAY.CENTRES Field in

T24 Arrangement Architecture -Deposits -

 Different Interest day basis for calculation of interest possible depending on

Different interest day basis for calculation of interest is possible depending on

T24 Arrangement Architecture -Deposits -

T24 Arrangement Architecture -Deposits -

Application specific Parameters

T24 Arrangement Architecture -Deposits -

 Tables used for building re-usable components :

T24 Arrangement Architecture -Deposits -

Tables set up during implementation:

T24 Arrangement Architecture -Deposits -

 Released by TEMENOS to define Actions and Attributes for any underlying

CUR, ACC, DUE, AGE, EXP, UND,

T24 Arrangement Architecture -Deposits -

T24 Arrangement Architecture -Deposits -

 Property is a named type / instance of a Property Class

To create a Product, we require Properties. In AA we can create named types

T24 Arrangement Architecture -Deposits -

 To be defined for every Property class, by associating Id of the respective

 Possible to create different Product Conditions for a Property Class

 Fields of a Product condition represent attributes of the associated Property

T24 Arrangement Architecture -Deposits -

 Product conditions have to be Date specific if Property class is set so

 Can be currency specific if the corresponding Property Class allows it

 Currency can be optional - e.g. Charge Product condition

 Currency and Effective Date form part of Product condition Id

 Possible to set conditions with future value date also

Attributes controlled by TYPE

T24 Arrangement Architecture -Deposits -

T24 Arrangement Architecture -Deposits -

NR.ATTRIBUTE NR.OPTIONS NR.TYPE NR.VALUE NR.MESSAGE

Usual term : 5 years. Can be negotiated,

NR.ATTRIBUTE Field is a multi value field.

T24 Arrangement Architecture -Deposits -