T3TAAC - Arrangement Architecture - Core-R13.2

T24 Arrangement Architecture - Core -
T3AAC - R12.1 1
The AA module provides a flexible framework that allows a number of products
to be created. It has the ability to allow user to construct banking products by
combining different business components through AA Product Builder. To create
a product, we will be using various product components such as Property
classes, properties and product conditions. Temenos has defined broad Product
Lines. We can create a product group under a product line. From a product
group, products can be designed as stand-alone products or as inheritance
products in a product family. The link between a product and an arrangement
will also be covered, checking out various activities in an arrangement.
AA also provides for simulating activities for “what-if” speculation for new and
existing product instances without creating or affecting live records.

T3AAC - R12.1 2
Almost all banking solutions including traditional T24, contain product silos.
The related functionality and product features exist within the respective silos.
In this instance, reusability is limited, creation of a new product / innovation /
modification in an existing product is difficult.
Innovation is about the Financial Institution’s ability to innovate new products
to offer their customers and thus maintain their competitive edge in the market.
We, as their partners, should have the ability to support such innovation with
product features and flexibility.
3
Till Arrangement architecture came into T24, each T24 module - AC, MG, LD,
MM, AZ etc. had a purpose built silo. Functionality and product features exist
within these silos. Each module has different product definitions and
parameters.
Under Account module , we have different types of accounts, such as Current
Accounts, Savings Accounts, Overdraft Accounts and various parameter tables.
Similarly under LD module, we have deposits and lending functionality, with its
own parameter tables. Each of the T24 Product modules have their own
parameter tables, transaction tables and processing logic.
Even to service a single product, multiple modules have to be implemented.
Local Developments for simple things like Availability of a product was
inevitable. Customisation involved additional local developments as per the
client’s requirements.
4
The AA module provides a flexible framework that allows a number of new T24
modules to be created. The application provides a business component based
architecture for the management of products. Using AA, we will be moving to a
modular Product architecture, whereby Users can create their own Products by
using the Components provided by Temenos, and these components can be
reused across many Products.

T3AAC - R12.1 5
In AA there is a three tiered Product Organisation comprising of Product Lines
defined by Temenos. Product Groups and Products are defined by Users.
Lending, Internet Services, Accounts, Deposits, Product Bundle are some of the
Product Lines in AA.
Every product is an assembly of many components. For example, for the
LENDING products, we have components like Term Amount, Payment Rules,
Limit, Periodic Rules, Accounting, Interest, etc. For Account products, we have
components like Account, Eligibility, Accounting, Charge, Interest etc. These
components are serviced in AA.
6
Product design and servicing are enterprise level functions. Functionality is
encapsulated in a set of common product components. Each component has its
own attributes and actions defined by Temenos.

T3AAC - R12.1 7
Product Lines are released by Temenos. Each product line is constructed by
combining the various, available, reusable components. Product lines e.g.
Lending, Deposits, Accounts, Product bundle, Relationship Pricing…….

T3AAC - R12.1 8
T3AAC - R12.1 9
BMW produces cars and they do not stop with one product, they also produce
motor bikes. These two items, whilst sharing a common purpose to transport
people, are clearly different Product Lines. We call these broad categories as
Product Lines.
Within their car product line, BMW has built a number of models which are
clearly segregated into groups such as the 3 series, 5 series, 7 series, etc. We will
refer them as Products Groups. These product Groups go on to form the highest
level in a complex product line hierarchy.
Within each product group, there are further subdivisions based on various
factors. For instance, the first subdivision is based on the body style of the car
such as a saloon, coupe or touring. This classification creates Product
Derivatives.

T3AAC - R12.1 10
Product Building structure clearly defines the Product families. The components
like engines, transmission, etc. can be used across different models. The
components have a high degree of reuse and this helps in assembling cars to fit
into the choice, needs, budgets, etc. of customers. This further helps customers
to get the product modified later with their choice. For example, a customer
would have selected a car with standard alloy wheels and later get the wheels
changed with spokes ones or radial ones. Financial institutions would like to
have the same flexibility and ease of designing and selling Products.

T3AAC - R12.1 11
Application of car model vis-à-vis the financial products is illustrated here.
Car Models could be organised first by Series such as 3-series, then by Model
Range such as 3-series Saloon, Coupe, etc and then by cars.
Similarly, AA Product Line “Lending” is organised first. Under it, there are
different Product Groups such as Mortgages, Home Loans, Personal Loans, etc.
have been created. Finally, each Product Group has multiple derived Products.
For example, the Mortgages Product Group has Products like 3 year fixed
mortgage, 5 year fixed mortgage, Floating Mortgages, etc.

T3AAC - R12.1 12
T3AAC - R12.1 13
T24 distinguishes its business applications as Account based and Contract based.
This comes from the underlying business of Banks which do allow balances in
accounts to switch from positive to negative sign on one hand. But on the other
hand a loan remaining always a loan and a deposit for a fixed period always a
deposit till its maturity. Balances in these contracts never switch their
accounting sign.
Account based products normally have some kind of account underlying such
as savings account or current account. Accounts of the Banks are either Nostro
Accounts or Vostro accounts. Based on the limit available for accounts, accounts
are classified as Overdrafts.
Contract type products include term loans, term deposits and long term
mortgages. There is regular payment of interest and redemption of principal in
these type of loans. Repayment may be linear / annuity / other method.
Arrangement architecture has revolutionized this concept.
Lending arrangements and Deposits arrangements have a term / maturity date.
However, Lending arrangements, Deposit arrangements and Accounts
arrangements are opened under T24 Accounts and balances in these can be both
positive or negative.

T3AAC - R12.1 14
T3AAC - R12.1 15
To recap Attributes are common features of a Component across different
Products. For example, the Component Engine has Attributes Fuel Type, Power
Output, Torque, etc. across different Products.
Similarly it has Actions or Functions like Start, Stop, etc. across different
Products.
Thus a Component has common Attributes and Actions across different

Products.
In AA we refer to these Components which have Attributes and Actions as a

Property Class. In the next Page, we will compare a Component of a Car and a
Property Class of a Banking Product to understand this concept better.

T3AAC - R12.1 16
The Components for vehicles vis-à-vis Banking products are compared.
In our example, the Wheel Component of vehicles are compared with the
Interest Component of Banking Products. Similar to other Components of
Vehicles viz. Transmission, Engine, Body, etc. we can think about the
Components Payment schedule, Charges, Term Amount (Period plus Principal)
of Banking Products.
In AA, the Attributes and Actions of Components are defined for every Property
Class.

T3AAC - R12.1 17
In some Products, there will be a requirement to have more than one Component
of the same type. These multiple instances of a Component will have the same
attributes but they could have different values.
For example, in case of a Car, the component Wheel has two instances Front
Wheel and Rear Wheel. Both of them viewed as the Component Wheel will
have same Attributes like Radius, Type, etc. but the values of these Attributes
might be different in case of Front and Rear Wheels. Similarly in case of a
Banking product, for example, in a Lending Product, there could be a
requirement to have two types of Interest viz. Principal Interest and Penalty
Interest.
In this case both belong to the Property Class Interest. But they could have
different values for the Attributes like Rate, Type, etc. These named types or
instances of a Property Class are termed as a Property in AA.
In AA, while Users can create new Properties based on Property Classes,
Property Classes themselves can be created only by Temenos.

T3AAC - R12.1 18
In a Product, we can have any number of Properties derived from a Property
Class, but the attributes of all such Properties are same as that of the Property
Class. They have the same Attributes and do the same actions. However, their
Attributes can have different values as explained earlier. It is the Properties
rather than the Property Classes, which are used to define the Products. Some
properties are hidden to prevent users from modifying / viewing the attributes at
arrangement level. For such a Property, the Property Type field is set as
‘Product.Only’.

T3AAC - R12.1 19
In AA, Product Lines which are combinations of Property Classes have been
defined by Temenos.
Some of the Product Lines unique to Banking Industry would be:
● Loans
● Deposits
● Accounts

T3AAC - R12.1 20
In AA under each Product Line, multiple Product Groups can be created by
Users. While the Product Line has been defined by Temenos which is a
combination of Property Classes, Users can create their own Product Groups
under a Product Line.
A Product Group is a sub-set of the Property Classes of its Product Line. Of

course, all the mandatory Property Classes need to be retained in a Product
Group and optional Property Classes may be included or omitted. Further, at a
Product Group level, we actually need to specify the Properties (atleast one) for
each Property Class.

T3AAC - R12.1 21
For example, a Product Line has 3 Property Classes: Account which is a
mandatory one, Interest and Charges which are optional. In the Product Group
formed under the Product Line, the Property Classes Interest and Account are
used, while the Charges can be omitted.
Further, under the Interest Property Class, we have two Properties - Principal
Interest and Penalty Interest. Under the Account Property Class we have only
one Property, Account.

T3AAC - R12.1 22
In AA under each Product Group, multiple Products can be created by Users. It
is finally the Products which a Bank can offer to its Customers.

T3AAC - R12.1 23
A Product Condition is a set of rules set for a Property Class. It defines the
default values for its Attributes. It is also used to define certain other conditions
like Negotiation Rules, etc. which we will discuss later. Example: For Interest
Property Class, we can define a Product Condition with the Interest Type
Attribute set to Fixed, Rate set to 5, and set other rules.

T3AAC - R12.1 24
In this animation, you can see the relationship between the Product hierarchy
and their building blocks.
A Product is where the Properties are linked to Product Conditions. As economic

and processing conditions may change over time, Users can optionally set an
effective date for such conditions.

T3AAC - R12.1 25
In AA, the Property Classes and Product Lines have been defined by Temenos.
The financial institutions can use these “building blocks” to construct the
individual Products which can be sold to their customers.
To summarise, the PROPERTY.CLASS definitions are released by Temenos and

cannot be amended with the exception of the description fields.
Every Property Class has some features called attributes. Each Property Class
can be defined with multiple Product Conditions. They are used to define a set
of default values for the Attributes of a Property Class and certain processing
rules.
Every Product Line is a composition of multiple Property Classes, some of

which can be set as Mandatory by Temenos. Users can create Product Groups
under a Product Line by linking Properties to respective Property Classes.
Please recollect a Property is nothing but a named instance of a Property Class
with all its Attributes and Actions.
Finally a Product is a saleable unit, attached to a Product Group. It is in a

T3AAC - R12.1 26
Product where the Product Conditions are linked to its Properties.

T3AAC - R12.1 26
Answers:
1. a
2. b
3. a

T3AAC - R12.1 27
4. a
5. b
6. a

T3AAC - R12.1 28
T3AAC - R12.1 29
To summarise the features of Product hierarchy:
It is possible for a Product to have only one Parent Product, while a Parent
Product may have multiple Child Products.
A Parent Product and child products down the line must be of the same Product
Group.
A Product can be set to either “saleable” or it could be only for inheritance.
What this means? When a Product is saleable, it means it is complete with
Product Conditions for all its Properties.
When it is only for inheritance, it means the Product is not complete i.e. All the
Properties of the Product are not defined with Product Conditions. In this case,
its only use will be to be a Parent such that Products at a lower level will inherit
its Properties.
It is possible to set a Parent Product also as saleable. This just means that in
addition to being saleable, its Properties can be inherited by its Child Products.
The benefits of Product Inheritance are :
 Clear organization of Product hierarchy
 Each saleable Product can be much simpler
 Differences between Products are immediately apparent
 Variations of Products can be easily done

T3AAC - R12.1 30
Earlier you have seen how a Car Product can be designed using inheritance and
Product hierarchy. Now you will be seeing the concept of Product hierarchy
with a financial example.
In this example, we have the Lending Product Line. The Product Line which has
been defined by Temenos has certain mandatory and certain optional Property
Classes.
The Product Group Mortgage under the Lending Product Line, has been defined
by User with Property Classes from that of Lending Product Line.
In addition, User has defined Properties for the Property Classes defined in the
Product Group and specified whether the Properties are mandatory or optional.
User can attach multiple Properties for a Property Class. For example, in this
case two Properties Principal Interest and Penalty Interest have been attached to
the Interest Property Class.
You will be seeing in the next page how a Product can be defined under this
Product Group. System will ensure that each mandatory Property Class of the
Product Line will have at least one Property defined in the Product level.

T3AAC - R12.1 31
Users can create Product Conditions for every Property Class and then attach
them to the Properties at a Product Level.
In the above example there are three Product Conditions for Term Amount
Property class. You can learn in detail about the Property Classes used here in
the AA-Lending course. The Property Commitment has been attached to the
Property Class Term Amount at the Product Group level.
One of the Product Conditions (25 yr Mortgage) of Term Amount Property Class
is attached to the Property Commitment at Product Level.

T3AAC - R12.1 32
In the above example, we have 5 Product Conditions for the Payment Schedule
Property Class. In the Product Group, the Property Repayment Schedule has
been linked to the Payment Schedule Property Class. At the Product Level, the
Product Condition (Constant Monthly) is attached to the Property Repayment
Schedule.

T3AAC - R12.1 33
Here the Payment Rules have two Properties Repayment and Principal Decrease
linked to it in the Product Group. One of the 4 available Product Conditions of
Payment Rules Property Class is attached to each of its associated Properties at
Product Level.

T3AAC - R12.1 34
The only Product Condition created for Accounting Property Class is attached to
its associated Property at Product Level.

T3AAC - R12.1 35
A product is created when Product Conditions associated with respective
Property classes are linked to relevant Properties at Product level.

T3AAC - R12.1 36
In the example, we have three levels of Products. For Capped Interest Mort
Product, parent is Flexible Mortgage. In turn, for Flexible Mortgage Product,
parent is Mortgage. Thus a 3 level product hierarchy has been formed. Top most
is defined with Product Conditions for some Properties and is set for inheritance
only. It is the same case for middle level Products which are also incomplete
even after inheriting Properties from parent. Middle levels are also set for
inheritance only. Finally, lower level Products are for sale. It is visible that some
Properties are re-defined with different Product Conditions at different levels.
Every level will inherit conditions from its higher level only for Properties not
defined in itself. This means Product Conditions defined for a Property both at
lower level and higher level, condition at lower level prevails over the one at
higher level.
For example, Interest Property is defined with different conditions at all three
levels. Lowest level Product will retain what is defined in it and will not inherit
interest condition from top. Capped Interest Mort Product will inherit conditions
from higher levels for all Properties other than the ones defined in itself. This
means that child Product will be available for sale with Product Conditions
defined at child level plus other conditions inherited from its parents.
Advantage of this is that it is simple to create new Products at lowest level,
which have slight variations to existing Products without going through whole
process of creating a new Product with Product Conditions for all Properties.

T3AAC - R12.1 37
Now that you have an understanding of how a Product is designed, we will see
what an Arrangement is. An arrangement is an instance of a Product associated
with a Customer. In simple words, for a financial Product, when a Product is
sold to a Customer, it becomes an Arrangement with the Customer.
Creating an Arrangement involves “negotiating” with the Customer for changes

to the standard product specification.
Technically an Arrangement is created with a copy of the Product Conditions,

some of which can then be modified, and some cannot.
You will learn about what is negotiation in the next page.
With the car analogy, the engine cannot be modified, the wheels can optionally
be modified, and the colour must be chosen. This means that while the engine
cannot be negotiated, the wheels and colour can be negotiated.

T3AAC - R12.1 38
Earlier, we have seen the linkage among Product Line, Property Class, Property
Class Attributes, Product Group, Property, Product and Product condition.
An arrangement is Customer specific offering of a Product. An Arrangement is

in fact a set of conditions called Arrangement Conditions which are inherited
from the Product Conditions of respective Product. For example, when a
Mortgage Product with LIBOR floating rate and 0.5% standard margin can be
offered to a Customer with standard margin reduced to 0.25%. In this case, the
Product Condition for the Interest Property has been modified at the
Arrangement level and it becomes an Arrangement condition. This modification
is possible only if the Negotiation Rules set at the Interest Property Condition
allows this.

T3AAC - R12.1 39
1. a
2. b
3. c

T3AAC - R12.1 40
T3AAC - R12.1 41
Product Builder of AA can be used to construct not only AA Products, but also
other select retail modules like Accounts, All in one Accounts, Loans and
Deposits and Mortgage modules. While AA products can be fully built and
serviced by AA, transaction type conditions of the T24 modules mentioned
above can be built with AA Product builder. As for other T24 modules and Non
T24 products, AA product builder can be used only to enable publishing them
into a common Catalog along with AA and select retail modules of T24.
AA Product Builder leads into Product Lines, which are predefined by Temenos.
Product lines currently available are Accounts (for retail accounts like Savings
and Current accounts), Deposits (for retail term deposits), Internet Services (for
ARC IB service configuration), Lending (for retail term lending products),
others (for any other T24 products and other Bank products for comparison
purposes) and Relationship Pricing (for Preferential Pricing). Product Bundle.
Product Lines can be created only by Temenos and they cannot be created by the
User.
These “building blocks” can be used to go to the next level of Product Groups,
which are pre-defined for select T24 applications. They are user definable for
other products.
The final stage is defining the Products which are completely user definable.
These individual Products are made available for sale to Customers by including
them in Catalog.

T3AAC - R12.1 42
Banks desire to have a single mechanism to define characteristics of a Product
from start to end, instead of setting different parameters for different aspects.
Likewise, they also want to have a single Catalog to display all products to
effectively sell them. Temenos solution of ARC – Acquire , Retain and Cross
sell – enables this. User can easily define all their products as well as
competitors' in a single Catalog through Arrangement Architecture (AA).
AA has its own set of products, like AA Loans and AA Deposits which could
be built by using AA Product Builder. This acts as a single mechanism to define
all characteristics of each AA product. This concept has been extended to cover
select parameter tables of select retail applications of T24. Accounts, All in one
accounts, Mortgages and Loans and Deposits modules can be covered.
Transaction type tables of these applications can be built and maintained by AA
Product builder. If they are built using AA Product builder , then later
maintenance is possible only though this builder. Before including them into a
common Catalog, it is also possible to link a version of T24 for them so that
from Catalog it is easy to access them. Non T24 products can be Catalogued for
comparison without any link to T24. , Product Catalog just shows the product,
and user has to create instances of products manually

T3AAC - R12.1 43
In product builder, the first step is to have broad product lines. These are pre
defined by Temenos. The Product lines are Accounts, Deposits, Internet
services, Lending, Proxy Services, Mobile Services, Relationship Pricing and
Other. These are pre defined to cover Retail accounts, Deposits, Preferential
Pricing, ARC Internet Banking services, Loans and other products.
From product line, we move to product groups which are built through
AA.PRODUCT.GROUP. These can be built by Users.
The property classes also have been pre defined for each of the Product Lines.
Thus, they get the basic attributes of the product line.
Property classes are pre defined by Temenos. The classes are like Interest,
General Charge etc. However every property class may have one or more
distinct properties. These are user definable. Under interest, user can define a
fixed interest or floating interest with or without margin as different properties
and pick what is needed for a particular product.

T3AAC - R12.1 44
AA.PRODUCT.DESIGNER application is used to define products. It is advised
to use the pre set versions to go from product line to product group and then on
to products.
Under a Lending product line, for a product group called PERSONAL.LOANS,
we can define any number of products. For one such product called
PERSONAL.LOAN, we can define all its properties like currencies allowed,
maximum Term, interest rate etc.
After defining the product, it is to be added to Catalog. This is a two step
process. When the product is getting defined, T24 does not check whether all
properties have been defined. However, when the product is subject to proof, it
validates its conditions, accounting rules and calculation sources. If all these
choices could be mapped, then proofing is successful. After that, it has to be
published to add to Catalog.

T3AAC - R12.1 45
T3AAC - R12.1 46
The primary tool for designing and publishing products is the Products
Configuration Screen which enables a user to
1) Browse Temenos defined Product Lines and amend descriptions if needed
2) View, amend and create Product Groups and
3) Products and
4) Proof and
5) Publish products
This comprises several parameter tables like AA.PRODUCT.LINE,
AA.PRODUCT.GROUP, AA.PRODUCT, AA.PROPERTY,
AA.PROPERTY.CLASS etc that are used to define Arrangement Architecture
products. The pre packaged tools help create and maintain products through
thoughtfully created composite screens, enquiries and versions.

T3AAC - R12.1 47
All product lines are pre configured. Few product lines can be used to configure
classic T24 modules - ACCOUNTS Product Line for configuring AC module,
LENDING Product Line to configure loan products in LD, MG and AZ module.
Full use of LENDING is made available to those who have installed AL (AA
Lending).
INTERNET.SERVICES Product Line is meant for configuring ARC Internet
banking services configuration. OTHER Product Line can be used to publish
other T24 products as well as other banks’ products for comparison.
While only Temenos can add new product lines in AA.PRODUCT.LINE, it is
possible for users to change description of these product lines as they desire.
This could be achieved by amending the existing description.

T3AAC - R12.1 48
View icon can be used to view existing records.
Edit icon in Product Lines can be used to change description of records in
AA.PRODUCT.LINE.
While T24 parameter tables cannot be automatically generated or maintained for
any product under OTHER product line, it is possible to link these products to a
T24 version and also include these in Product Catalog.

T3AAC - R12.1 49
By using the icon for Drilling down to instances, users can choose a Product line
and can drill down to view existing product groups and from there to view the
existing Products for the desired group. If the user does not want to amend an
existing product, they can choose to create a new product.
By using the icon for New instances, users can create records at the next level.
While at Product Line, if this icon is clicked, then it is possible to create new
record in Product group in application AA.PRODUCT.GROUP. While at
Product group, if this icon is clicked, then it is possible to create new record in
AA.PRODUCT.GROUP.
While product lines are pre defined by Temenos, it is possible to define new
product groups in AA Loan under LENDING product line. For AC, AZ, LD and
MG modules, records in AA.PRODUCT.GROUP are already pre defined.
Product groups for any other products can be defined under OTHER product
line.
While creating new product groups, Group type can be set as INTERNAL or
EXTERNAL. INTERNAL means that the group being defined is the Bank's
own product and is available for sale to its customers. At times, it may be
necessary for a Bank to do comparison between its own product and one by its
competitor to show how its product is superior when compared to products of
other Banks.. Hence, products of others can be defined as EXTERNAL, which
are not available for sale here.

T3AAC - R12.1 50
T3AAC - R12.1 51
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.
The components are reusable and can be used across several Products.

T3AAC - R12.1 52
Property Classes are building blocks, released by Temenos and you can only
amend their Description.
Financial institution uses these functionality of “building blocks” to construct
individual products which are available for sale to its customers.
CCY – Product conditions for the same product will vary by currency (e.g.
interest and principal conditions). The product property condition definition
(AA.PRD.DES.xxxxx) will contain currency in the key. If CCY is not defined
then property will NOT be based on currency.
OPT.CCY - Indicates that properties may or may not have Currency component
in them. But it needs to have a default non currency condition and when a
explicit currency condition is not stated, it picks the default condition for
processing. Currently only CHARGE property supports OPT.CCY option.
DATED – Product conditions can vary by date and relevant dated property
definition should be used when performing processing. The product property
condition will contain an effective date in the record key. If DATED is not
specified the record will not contain a date.
MULTIPLE – Allows more than one property of that class to be defined for a
single product. If MULTIPLE is not specified only one property of this class can
be linked to an AA product.
MERGE – Allows Child condition not to override parent condition blindly.

T3AAC - R12.1 53
FORWARD.DATED – Allow users to define conditions applicable on a later
date at the Arrangement level. When an action is initiated on an arrangement
involving this activity, system will show the condition which is currently
applicable and also future condition if any. Future condition can be added,
amended or deleted by the user, but conditions which are currently applicable
cannot be deleted. Currently enabled for ACTIVITY.CHARGES,
ACTIVITY.RESTRICTION, CHARGE, INTEREST and PAYMENT.SCHEDULE.
ARRANGEMENT – A new arrangement condition is applied to this property
every time an Activity affects it, provided negotiation is allowed at product
condition level. TRIGGER – Properties related to this property class will not
appear in Arrangement Activity screen. When certain activities related to these
property classes are triggered and validated in the Arrangement activity,
property associated with this property class appears in the arrangement. E.g.
Charge Override – This Property appears in an arrangement after an Activity
charge is triggered and validated. VARIATION: Property Class that has
Variation in Type field can have an additional component in the Product
condition. For example, Interest product condition FIXED.RATE-USD-
20120101 can have the key “FIXED.RATE-USD-INTERNET-20120101” to
hold specific interest conditions for products subscribed through “Internet”.
The 3rd component in the key “INTERNET” should be a valid entry in the
EB.LOOKUP file. Variation enables products to be offered to Customers

T3AAC - R12.1 54
through various channels.

T3AAC - R12.1 54
TRACKING – Certain types of property (e.g. interest conditions) may be
defined at the product level and the arrangements of that product simply 'track'
the product definition and do not require any definition at the arrangement level.
If TRACKING is specified then a property of this class can be defined as
TRACKING, CUSTOM.TRACKING or NON-TRACKING in the product
definition.
NON.TRACKING - Indicates that the properties belonging to this class should
only have fixed link behaviour. In other words, these properties may not have
CUSTOM.TRACKING or TRACKING link to the arrangement.
TRACKING.ONLY - Indicates that the properties of this class can ONLY have
tracking behaviour. Also, the properties of this class should be stated as
PRODUCT.ONLY in AA.PROPERTY.
BALANCE.PREFIX : A property class can hold related financial balances This
field holds the allowed prefixes for use in the balance type and should reflect the
possible stages in the lifecycle. Values should be 3 alphanumeric.
CUR - The current or live value of the property balance; ACC - The current
accrued balance for the property; DUE - The due balance for property; AGE -
An aged balance where the prefix will be determined by the overdue status. A
value of AGE here denotes that the balance can move through multiple stages
based on the OVERDUE property definitions.

T3AAC - R12.1 55
AA.PROPERTY.CLASS.ACTION is the application which holds information on
actions which can be performed with a PROPERTY CLASS
The user will be able to get information on whether the action will generate an
accounting entry and also which Product Line will be affected.

T3AAC - R12.1 56
Please view the record existing under Property Classes – Customer and Term
Amount.
View details tab as also the balance pre-fix as applicable to each product line.
Discuss the basic attributes.

T3AAC - R12.1 57
Customer Property class has attributes Dated and Non-Tracking. This indicates
that the product condition will have date as part of its record Id and being
marked as Non Tracking, this property cannot be tracked. Please note that there
are no balance prefix defined for this property.
Term Amount property class has attributes CCY, Dated and Non-Tracking. The
product condition of this property has currency as part of its record Id. When the
product is to be made available in say, 4 different currencies, product conditions
have to be created in all of these 4 currencies. This also indicates that the
product condition will have date as part of its record Id and being marked as
Non Tracking, this property cannot be tracked.
Balance prefix is CUR & TOT for Lending product Line and TOT for Deposits
product line. This indicates that this property needs to have balance types
defines before using them in our Product Group and Product. Term amount
property class does not apply to Accounts Product Line, while Customer is
mandatory for all financial product lines.

T3AAC - R12.1 58
Now that we have learnt about a Product Group, we will go into a Product. We
sill start with Properties.
In AA we can create named types (instances) of a Property Class which are
known as PROPERTIES.
AA.PROPERTY is the T24 application that is used to create properties.
As you have seen earlier, you can attach multiple properties to a Property Class
in a Product Group, provided it is allowed in the Property Class.
PROPERTY.TYPE: It can have a null value or one of the values: Product Only,
Suspend, Suspend Overdues, Residual accrual, Credit, Forward dated, Accrual
by Bills

T3AAC - R12.1 59
PRODUCT.ONLY: The Property details will be hidden at an Arrangement level,
and user cannot view or amend them. For example, Properties under
ACCOUNTING Property Class will have this value. It is to prevent the User
from viewing or modifying Accounting rules at an Arrangement level. It is
enough if the Property is attached to the Product.
SUSPEND: Currently, it is applicable only to Properties under Property Classes:
INTEREST and CHARGE. This means that Property would be allowed to be
suspended. For example, accrual of Interest can be suspended.
SUSPEND.OVERDUE: Existing Overdues in the Property will be also
suspended when the Property is suspended. This goes along with the value
SUSPEND i.e. SUSPEND also be one of the values of PROPERTY.TYPE.

T3AAC - R12.1 60
Residual Accrual - When interest accrued is greater than the amount made due
for interest for that period, excess amount is moved to RES<INTEREST>
balance of this property
Credit – This Property is payable to customer, Applicable for charge property,
e.g. bonus
Forward dated - The property needs to be set as FORWARD.DATED in type
field of AA.PROPERTY file so that the forward dated conditions appear
alongside the current condition as multiple tabs, for negotiation at a later date
Accrual by Bills – The system accrues the penalty interest which is stored in
AA.INTEREST.ACCRUALS .It allocates the accrued penalty interest
proportionally to each bill based on the calculation balance. If interest property
is set as “ACCRUE.BY.BILLS”, then routine AA.ACCRUE.BILL S will be
called after normal accrual process is completed to update bill details, with
accrual corresponding to that bill.
Null indicates that it is a normal property, there are no special features

T3AAC - R12.1 61
Create new property for Customer Property Class

T3AAC - R12.1 62
Input property names as desired in record Id for Customer. Give GB description
and full description as applicable.
See that the respective property class is automatically defaulted. Commit the
record.

T3AAC - R12.1 63
We now know how to create a Property. But it is the Product Condition which is
practically used in a Product to default values in an Arrangement and to control
their modification. We will go into details of the Product Conditions now.

T3AAC - R12.1 64
What is the underlying application that is used to store all the information about
Product conditions?
Do you still remember?

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>.
You will see an example for this in the next page.

T3AAC - R12.1 65
Product condition can be currency-specific. You may notice that
TERM.AMOUNT Product Condition, Currency USD is part of Id.
If Property classes has TYPE set to CCY then Product condition can 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. For
example we have a Product Condition called FIXED.INTEREST-USD. If you
support a GBP as well, you need a Product Condition called FIXED.INTEREST-
GBP. When assigning conditions to a Property the user simply assigns the
condition FIXED.INTEREST . When a new arrangement is created appropriate
conditions for currency of arrangement will be used.
TYPE = CCY - Specifies whether Properties created for a Property Class can
have Product Conditions based on currency or not. If TYPE field contains a
value CCY, then Product Conditions for property will vary by currency. Product
condition definition will contain currency in key. If CCY is not defined,
property will NOT be based on currency.
TYPE = DATED - Specifies whether Properties created for a Property Class can
have date Product Conditions or not. If this field contains a value DATED then
Product conditions can vary by date and relevant dated property definition will
be used when processing. Product Condition will contain an effective date in
record key. If DATED is not specified record will not contain a date.

T3AAC - R12.1 66
The currency forms a part of the ID of Product Conditions that are currency
specific.
Assumption: TRG Product contains the a property that is of TERM.AMOUNT
type. The TRG Product supports USD and GBP.
Question: How many Product conditions needs to be created for the property
which is an instance of TERM.AMOUNT Property class?
Answer: We will have to create two Product conditions. One for USD and
another for GBP.

T3AAC - R12.1 67
Each Product Condition record in T24 has an Effective Date. The effective date
represents the date on which that particular set of values takes effect for a
Product and for any Arrangements which “track” Changes to Product Conditions
are typically controlled by effective dating. Note that any Product Condition can
be set for Tracking at a Product level.
This allows you to set up any changes to Product Conditions in advance, and
when Product using the conditions has been re-published, they will
automatically switch over to the new condition on the effective date.
When you do not specify a date in the Id of a Product Condition, date part of
the Id defaults to the today’s system date.

T3AAC - R12.1 68
After you create a record for a Product Condition with a new effective date, it is
essential to proof and publish all the Products to which the Condition has been
attached. Then the new condition values will be used in Arrangements created
on or after the effective date. You will learn more about proofing and publishing
later in this course.

T3AAC - R12.1 69
To summarise, the currency and effective date of a Condition are part of ID of a
product condition. The currency defaults to the local currency and the effective
date defaults to System date. So to create a USD condition with a future
effective date, enter the ID as the name of the condition, then a hyphen, then the
currency, then a hyphen, then the date.
Example, FIXED.RATE-USD-20080315.
IF type of a property class is CCY, then its product conditions should be
currency specific. CCY will be part of Id.
IF type of a property class is DATED, then its product conditions should be Date
specific. Date will be part of Id. The date represents effective date of the
product condition.
IF type of a property class is OPT.CCY, then its product conditions may be
currency specific. CCY may or may not be part of Id. IF no currency is
specified, then two - - will be defaulted after Product condition identifier.
Currently CHARGE Property class is OPT.CCY type.

T3AAC - R12.1 70
You can see here a model Product Condition set for the TERM.AMOUNT
Property Class.
Default Values
You can see there are different fields like Amount, Term, etc. which are the
attributes of the TERM.AMOUNT Property Class. Here, we have defined a
value of “25Y” for Term and “No” for Revolving. When this Product Condition
is attached to a Property (of the TERM.AMOUNT class) in a Product, these
values will be defaulted in an Arrangement created for the Product.
Negotiation Rules
We will learn about this tab in the later part of this course.

T3AAC - R12.1 71
Negotiation Rules are used to specify which attributes may be amended at the
Arrangement level, and which must remain the same across all Arrangements.
For each attribute that is modifiable, the negotiation rule defines the rules by
which they may be modified.
For example, a product may be specified as having a base term of 5 years. At the
arrangement level, the bank may wish that the user have the ability to negotiate
from 3 to 10 years, A user would define a negotiation rule on the
TERM.AMOUNT property condition for the TERM attribute with a
“MINPERIOD” of 3Y and a “MAXPERIOD” of 10Y.
Another typical example would be the amount of a loan. Most loan products do
not have a default value but rather have a minimum and maximum amount. This
is accomplished by the definition of two negotiation rules on the Term Amount
property for the AMOUNT attribute.

T3AAC - R12.1 72
This is an example of negotiation rule for a product condition. We will see more
of this, in detail, in the coming slides.

T3AAC - R12.1 73
Now, we will go into the fields of Negotiation Rules tab and find out what they
stand for.
Field: DEFAULT.NEGOTIABLE, It is a Mandatory field.
It has 2 Options: Yes and No.
It defines whether all attributes (fields) of the Property Class can be negotiable
or not - at a top level.
This top level rule can be over ruled for specific attributes by setting the fields
below. In this instance, UPDATE.COMMT.LIMIT and REVOLVING Fields set
as Non-negotiable will override the Default Negotiable setting of Yes at top
level.

T3AAC - R12.1 74
T3AAC - R12.1 75
We will now look into the Field NR.OPTIONS. It is a sub-valued field i.e. it can
have more than one value for each Attribute.
NR.OPTIONS has a list of options with values:

Negotiable
Non-Negotiable
Override
Fix value
Mandatory
We will explain about these values in the next page.

T3AAC - R12.1 76
The value NEGOTIABLE indicates that the associated Attribute (i.e. field) can
be negotiated (amended) at the arrangement level.
The value NON-NEGOTIABLE indicates that the associated Attribute cannot be
amended at the arrangement level.
Both NEGOTIABLE and NON-NEGOTIABLE cannot be defined together.
The value OVERRIDE specifies if a default override message should be
generated whenever the default value is modified at the arrangement level.
This feature will be useful for the Authoriser to know which of the defaulted
values have been modified at the Arrangement level.
If OVERRIDE is not specified, no override will be generated.

T3AAC - R12.1 77
Some of the Attributes have been set as Mandatory at the Property Class and this
setting cannot be changed.
However, you can set an optional attribute as Mandatory, by specifying the
value MANDATORY. The value MANDATORY specifies if the Attribute is
mandatory for this product condition. Can only be specified where the Attribute
is not defined as mandatory in the property class.
This means a value has to be mandatorily input for this attribute at the
Arrangement level.
The value FIX-VALUE specifies if the Attribute value is to be fixed at the
arrangement level. If FIX-VALUE is not specified, the Attribute value will vary
with the changes to the underlying product condition.

T3AAC - R12.1 78
We will look into NR.TYPE here:
This specifies the rule for comparing the value input in an Arrangement against
set values here.
For example, MINIMUM against Amount attribute means the value input in the
Arrangement should have this minimum value.
This is sub-valued within an Attribute, and thus it is possible to define more than
one negotiation rule for an Attribute.
MAXIMUM indicates the Amount attribute can go up to this maximum value.
The NR.TYPE input must be a valid record ID from EB.COMPARISON.TYPE
table.

T3AAC - R12.1 79
NR.VALUE
This field specifies the value that links to the rule in field NR.TYPE.
This is the value(s) to compare against the value input in the Arrangement.
NR.MESSAGE
Specifies whether to raise an error or override message when the rule is broken
at the Arrangement level.

T3AAC - R12.1 80
We will now look into the Field DEFAULT.ATTR.OPTION. It is an optional
field.
Allowed Values are RESETTING and NON-RESETTING.
RESETTING denotes that during any Renewal Activities (for eg :
CHANGE.PRODUCT, RESET) the arrangement conditions will be reset from
the Product.
NON-RESETTING denotes that during any Renewal Activities arrangement
conditions will be maintained from the Arrangement level.

T3AAC - R12.1 81
Let us see a Negotiation Rule set in a Product Condition to TERM.AMOUNT
Property Class, which has attributes for Term, Amount, etc.
You can see that default values for Amount is set to null value, Term to 25Y,
Revolving to NO and UPDATE.LIMIT to None. Here, by default all attributes
of Term Amount Property Class are negotiable i.e. they can be modified in an
Arrangement. Restrictions to this general rule is defined under a set of
associated fields starting with ATTRIBUTE. Since Amount does not have a
default value, it will be null in an Arrangement. Amount is a mandatory
Attribute and User will input the value and commit. When the amount is less
than 200000, it will be an error condition. When the amount exceeds 750000, it
will raise an override message. Though by default all attributes are negotiable,
there is an exception to this rule.
Both the attributes UPDATE.COMMIT.LIMIT (set with a default value of
NONE) and REVOLVING (set with a default value of NO) are not negotiable
i.e. their defaulted values cannot be modified in an Arrangement.
Please note that we have not set any rule for the Attribute TERM. What will
happen to that? By default any attribute is negotiable.
Thus TERM is negotiable. It will be defaulted with the set value of 25Y in an
Arrangement. Since no rule has been set for this attribute, User can modify it to
any value in an Arrangement.

T3AAC - R12.1 82
Let us see a Negotiation Rule set in a Product Condition to TERM.AMOUNT
Property Class, which has attributes for Term, Amount, etc.
You can see that default values for Amount is set to null value, Term to 25Y,
Revolving to NO and UPDATE.LIMIT to None. Here, by default all attributes
of Term Amount Property Class are negotiable i.e. they can be modified in an
Arrangement. Restrictions to this general rule is defined under a set of
associated fields starting with ATTRIBUTE. Since Amount does not have a
default value, it will be null in an Arrangement. Amount is a mandatory
Attribute and User will input the value and commit. When the amount is less
than 200000, it will be an error condition. When the amount exceeds 750000, it
will raise an override message. Though by default all attributes are negotiable,
there is an exception to this rule.
Both the attributes UPDATE.COMMIT.LIMIT (set with a default value of
NONE) and REVOLVING (set with a default value of NO) are not negotiable
i.e. their defaulted values cannot be modified in an Arrangement.
Please note that we have not set any rule for the Attribute TERM. What will
happen to that? By default any attribute is negotiable.
Thus TERM is negotiable. It will be defaulted with the set value of 25Y in an
Arrangement. Since no rule has been set for this attribute, User can modify it to
any value in an Arrangement.

T3AAC - R12.1 83
Controlling Attribute values of an Arrangement over a period of time is done by
Periodic Rules, which in turn depends on Periodic Attributes.
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. 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.
E.g. A periodic rule is attached to the interest condition based on rate increase
tolerance over a period.
Users are also allowed to create periodic attribute class from R13.
T24 Arrangement Architecture -Loans -

T3TAAL - R12.1 84
Create a new Product condition for Term Amount property class.
Set the following rules:
Term to default as 3Y, but Negotiable between 1 and 5 years
To produce overrides if negotiated otherwise
All attributes, by default are Negotiable

T3AAC - R12.1 85
A new Term amount product condition with ID as TEST.TERMMAT is created.
Please note the default date and currency in the record ID. Term is input as 3
years, the attribute is left negotiable with a minimum period of 1Y and a
maximum period of 5Y, override is marked for negotiation beyond these.
Default negotiable is marked as Yes.

T3AAC - R12.1 86
1. b
2. c
3. b

T3AAC - R12.1 87
T3AAC - R12.1 88
Classes are released by Temenos and you can only amend their Description.
The screen here shows the Product Hierarchy in AA and what they are about at
each level.

T3AAC - R12.1 89
Classes and Product Lines are released by Temenos and you can only amend
their Description.

T3AAC - R12.1 90
The Product Line provides a high level definition of the business components
(Property Classes) that may be required to construct a product belonging to that
line. For example the LENDING Product Line will enable users to design and
service term loan products such as Loans (personal, small business, etc.)
Mortgages Lines of Credit
The Product Lines are defined by Temenos and cannot be created by the User. A
Product Line is described by the Property Classes which constitute it. The
financial institution may then use these “building blocks” of functionality to
construct the individual products which are available for sale to its customers.
LINE.ATTRIBUTE: This optional field is used to specify whether the product
line deals with amounts/currencies and whether it supports reverse replay
mechanism. Possible values are CCY, REPLAY,NULL
For example LENDING product lines deals with amounts/currencies where as
product line like INTERNET.SERVICES do not involve amounts/currencies. If
this field contains a value CCY, it means that the products of this line deal with
amounts.
If any back dated activity is triggered, all the activities performed from the
given back date till today are reversed, the current activity is applied and all the
reversed activities are replayed taking into effect the conditions altered by the
backdated activity. This is called reverse replay. Product line with

T3AAC - R12.1 91
LINE.ATTRIBUTE as REPLAY, supports reverse and replay mechanism.

T3AAC - R12.1 91
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

T3AAC - R12.1 92
View the record existing under LENDING, ACCOUNT and DEPOSITS
Product line.
View details in Tab sections - Product lines and Property Classes.

T3AAC - R12.1 93
Under Product Lines tab, all three Product Lines, namely Lending, Accounts and
Deposits contain description plus CCY and REPLAY under the Line attribute.

T3AAC - R12.1 94
Under the Property Classes tab of Lending Product Line, these are the valid
Property classes.
Please note that whether the Property class is mandatory or not is also indicated
here.

T3AAC - R12.1 95
Under the Property Classes tab of Accounts Product Line, these are the valid
Property classes.
here.

T3AAC - R12.1 96
Under the Property Classes tab of Deposits Product Line, these are the valid
Property classes.
here.

T3AAC - R12.1 97
We will look into how you can design an AA Product beginning with Product
Group. Please recollect that the Product Group is in the second level of Product
organisation. Users can create their own Product Group under existing Product
Lines. Each Product Group has a number of Properties associated with it and
specified as Mandatory or not. Each Product Group must have one Mandatory
Property for each of the mandatory Property Classes of its Product Line. All
Products belong to a Product Group.
GROUP.TYPE Field : Valid options are INTERNAL and EXTERNAL
INTERNAL – means the group being defined is own Bank's product. Only
products specified as INTERNAL are available for sale to customers.
EXTERNAL - There may be a necessity for Banks to do comparison between its
own product(INTERNAL) and one by its competitor. Those groups may be
defined as EXTERNAL. These products may then be used for comparative
analysis to show the superiority of Bank's own product. Products of this type are
not available for sale to own customers.
REBUILD.ACTIVITIES field is used to rebuild AA.ACTIVITY records from
AA.ACTIVITY.CLASS. AA.ACTIVITY is an instance of
AA.ACTIVITY.CLASS, records would be created on AA.ACTIVITY for all
instances(properties)of class(property class) at authorisation stage. This can be
used to rebuild activities when a new property is introduced into a group.

T3AAC - R12.1 98
We will discuss about AA Activities in the later part of the course.

T3AAC - R12.1 98
Create a new Product Group with the Property classes
and properties as given above.

T3AAC - R12.1 99
A new Product Group ‘TRGPRODGROUP’ is created under Lending Product
Line with appropriate inputs in Property class, Property and Mandatory fields as
given in the workshop.

T3AAC - R12.1 100
Id: Id can be input with a name and an effective date separated by a hyphen. If
no date is input, T24 will automatically default the system date. If a record with
a future effective date is created for an existing Product, T24 will automatically
default all field values from the existing record. Effective dating a Product is
useful to offer a Product initially for some time with certain Properties and then
modify its structure from a future date.
DESCRIPTION and FULL.DESCRIPTION: Description about the Product.
PRODUCT.GROUP: The group to which the Product belongs to.
PARENT.PRODUCT: (Optional Field) Product to which current Product is a
Child Product. If it is set,, then Product need not be complete with all Mandatory
Properties. It will inherit Properties not defined at its level, from Parent Product.
INHERITANCE.ONLY: Value YES signifies that this Product cannot be offered
directly for an Arrangement with a Customer. Its purpose is that other Products
can inherit from this Product by linking this Product as their Parent.
Inheritance Only products do not undergo full proofing validations nor are they
available for sale on their own. They are only abstract definition of a product
which should be derived down the hierarchy to define the product in its entirety.

T3AAC - R12.1 101
T24 product builder follows a structured way of defining products. Each product
should have all the mandatory properties and any of the optional properties of its
product group defined along with a product condition for each of the property.
You can define more than one product condition for a property. In such cases,
you should specify when the subsequent condition would be effective from
arrangement date and the same can be specified in EFFECTIVE Field.

T3AAC - R12.1 102
You can define the subsequent links between a product and its arrangements.
ARR.LINK.TYPE Field is used to determine whether subsequent changes of
conditions in product should have its effect on the existing arrangements. The
three options are TRACKING, NON-TRACKING and TRACKING.ONLY

T3AAC - R12.1 103
NON.TRACKING
Arrangement attributes are unaffected by product-level changes. At the
Arrangement level, Attributes can be negotiated, subject to Negotiation Rules in
corresponding Product Condition.
TRACKING
When TRACKING is set in the ARR.LINK for a Product Condition, then
changes to the Attribute values at the Product Condition level will be reflected
in an Arrangement throughout its life.
In this case, the Product Condition must have default values for all its
mandatory Attributes and user can not input value for any Attribute. Any
negotiation rules set in the Product Condition will be just ignored. To set this
functionality, in the PROPERTY.CLASS, the TYPE field should have
TRACKING as a value.
CUSTOM.TRACKING
This is similar to Tracking with some differences. If negotiation rules are set for
some Attributes at the Product Condition level, User can input their values at
Arrangement level. When an attribute is negotiated at the arrangement level or if
it is set to Fix-Value in Product Condition, it will not track changes to Product
Condition. All other Attributes will track changes to Product Conditions.

T3AAC - R12.1 104
There is a relation between the TYPE field of a Property Class and how the
ARR.LINK Field can be set for its Product Condition in a Product:
If TYPE is set to TRACKING
ARR.LINK can be set to TRACKING or CUSTOM.TRACKING or

NON.TRACKING. It indicates that the given property can be set to tracking.
If TYPE is set to NON.TRACKING
ARR.LINK can only be set to NON.TRACKING
If TYPE is set to TRACKING.ONLY
ARR.LINK can be set only to TRACKING

T3AAC - R12.1 105
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.
Validation rules:
The property stated here would be validated in the proofing stage to verify if
they actually belong to this product.

T3AAC - R12.1 106
1. c
2. c
3. b

T3AAC - R12.1 107
Create a Product under the Product Group created in the earlier workshop. At
least one product condition is to be attached to each property. Set the calculation
source tab as indicated.

T3AAC - R12.1 108
TRGPRODUCT is created from TRGPRODGROUP. The properties opted for in
the product group are defaulted while creating the product. Suitable product
conditions are filled in, arrangement link is set for tracking / non-tracking.
Under calculation source tab, CURACCOUNT is set as the balance property for
calculating Principal Interest on daily debits. Please note that under the
availability tab, currency is defaulted as USD.

T3AAC - R12.1 109
T3AAC - R12.1 110
Create another Product under the Product Group created in the earlier workshop.
This product is to be defined as a Parent product by marking
INHERITANCE.ONLY. At least one product condition is to be attached to each
property. Set the calculation source tab as indicated.

T3AAC - R12.1 111
We are creating a parent product named TRGPARENT. The properties opted for
in the product group are defaulted while creating the product. Out of 9
properties, only 6 are chosen for the parent product, rest will be defined in the
child product. Suitable product conditions are filled in, arrangement link is set
for tracking / non-tracking.

T3AAC - R12.1 112
Create a Product under the Product Group created in the earlier workshop. This
is a child product of the parent created in the earlier workshop. At least one
product condition is to be attached to each property. Set the calculation source
tab as indicated.

T3AAC - R12.1 113
We are creating a Child product named TRGCHILD. This product is the child
of TRGPARENT product and is under the same product group –
TRGPRODGROUP. The properties opted for in the product group are defaulted
while creating the product. Out of 9 properties, only 4 are chosen for the child
product, rest were earlier chosen in the parent product. Suitable product
conditions are filled in, arrangement link is set for tracking / non-tracking.
Under calculation source tab, CURACCOUNT is set as the balance property for
calculating Principal Interest on daily debits.

T3AAC - R12.1 114
T3AAC - R12.1 115
A Product in AA goes through three processes – Product designing, proofing and
publishing.
Designing is the Process of creating Products and attaching Product Conditions

to their Properties. It is done using the T24 Product Browser.
When a Product is designed, it has to undergo Proofing process. Proofing

validates that the Product has been configured correctly without errors, and is
ready for release. Proofing is the process that checks whether the Product is in
sync with its hierarchy such as Parent and or the associated Product Group.
Once a Product is proofed, it has to be published. Publishing is the process by

which a Product is put into Product Catalog. Once a Product is published into
Product Catalog, it is available for sale. When a parent Product is proofed and
published, these functions are performed down the line to all the child Products
under it. In this case it is not necessary to individually proof and publish the
child Products.
New Arrangements can be created only for a Product published into Product

T3AAC - R12.1 116
Catalog.

T3AAC - R12.1 116
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. Proofing validates that the Product
has been configured correctly. Proofing includes checking whether all
mandatory Properties have been given conditions, that there are no conflicts
between those conditions, and any other errors that would prevent the Product
from being published. Any errors generated have to be fixed and the product
has to be proofed again. Then the Product is published, and it enters the Product
Catalog. Now the product is available for sale and can be used to create
Arrangements.
The proofing and publishing process can be done either “Online” or by running
a “Service” in the AA.PRODUCT.MANAGER application. If ONLINE is
chosen, system would proof the product immediately. If SERVICE is chosen, the
main product (from which the publishing is triggered) is written on to a LIST
file AA.PUBLISH.SERVICE.LIST for indicating whether it is a
PROOF/PUBLISH initiation. A Service would be introduced –
AA.PUBLISH.SERVICE – which would process this list file. The service would
publish products hierarchy-wise. This ensures that a child would not
accidentally get published before the parent has been processed.

T3AAC - R12.1 117
When you publish a Product, you have to define 2 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.
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.
PRODUCT.ERROR Field displays the errors caused when Proofing fails.
SUGGESTION Field displays suggestions for rectifications of errors.

T3AAC - R12.1 118
Proof the Parent Product used in the previous workshop with available date as
today, then publish the same.

T3AAC - R12.1 119
The parent product is proofed with available date as today’s date and Online
opted. On proofing being successful, status monitor shows the status as
completed successfully. Then publishing is done, again, on publishing being
successful, status monitor shows the status as completed successfully

T3AAC - R12.1 120
Answer:
1. c
2. b
3. b

T3AAC - R12.1 121
T3AAC - R12.1 122
Before we move further into Activities, we will recollect that an Arrangement is
an agreement between the bank and the customer whereby the bank agrees to
provide services associated with a Product.
If it is a Financial Arrangement, it also has a currency and account for lending
products.
All arrangements have an agreement date. Arrangements can be created after
product available date.
Finally, arrangements has Arrangement Conditions. This is the set of Properties
defined for the Product with their conditions.
Creating an Arrangement involves “negotiating” changes to the standard product
specification. All the attributes that were specified as negotiable can be
amended.
Technically an arrangement is created with a copy of the product conditions,
which then hold the values for the specific arrangement. So the arrangement is
not simply held in a single record, it is spread across multiple records. This is
why it is easier to use the enquiries and composite screens provided rather than
try and look at files directly.

T3AAC - R12.1 123
Create an arrangement for Mortgage product and set the following:
Change term to 2Y
Indicate a commitment amount of 50,000.
nput a settlement account under Pay In settlement tab, input the payment
type as Full
In Pay Out settlement tab – update Active field as “No”
Remove the payment type Disbursement.% from the Schedule
Commit the Arrangement, accept overrides and get it authorised

T3AAC - R12.1 124
An arrangement is created under Mortgage product, picked from the catalog.
Term is changed to 2Y
Commitment amount is input as 50,000.
Settlement account under settlement tab is input, payment type is
indicated as Full.
When the Arrangement is committed, overrides for activity charge and
unauthorised overdraft are generated.
Overrides are accepted and the arrangement is later authorised.

T3AAC - R12.1 125
Create an arrangement for Long Term Deposit product and set the
following:Set the term as 1Y, the amount as 75,000
Settlement account to be given suitably in Pay Out Settlement Tab
Pay In settlement tab – update Active field as “No”
Commit the Arrangement and get it authorised

T3AAC - R12.1 126
An arrangement is created under Long Term Deposit product, picked from the
catalog.
Term is input as 1Y
Commitment amount is input as 75,000.
Settlement account under settlement tab is input.
Arrangement is committed.
Then, the arrangement is authorised.

T3AAC - R12.1 127
Create an arrangement under Current Account Group and select the Current
Account product.
Commit the Arrangement and get it authorised.

T3AAC - R12.1 128
An arrangement is created under Current Account Group by selecting the
Current Account product.
The Arrangement is committed and then, authorised.

T3AAC - R12.1 129
AA.ARRANGEMENT.ACTIVITY Application is used to trigger activities for
arrangement.
Where does the arrangement actually gets stored?

We know that the Product Conditions are based on Property Classes. Product
Conditions belonging to a particular Property Class are stored in a separate
application that corresponds to the respective Property Class.
Are the Arrangement conditions/values also grouped based on Property class?

Yes!
An arrangement gets stored in AA.ARRANGEMENT, whereas the arrangement

conditions relating to the various Property Classes are stored in applications that
begin with AA.ARR.<Property Class Name>.

T3AAC - R12.1 130
In this screen, you can see where the Product Conditions and the corresponding
Arrangement Conditions (values at Arrangement level) are stored.
The basic elements like Customer, Product, etc. are stored in
AA.ARRANGEMENT.
The Product Condition for Customer Property Class is stored in
AA.PRD.DES.CUSTOMER, while the Arrangement values for the Property
related to Customer Property Class are stored in AA.ARR.CUSTOMER.
Similarly, for OFFICERS and ACCOUNT Property Classes.
Note that an application named AA.ARRANGEMENT.ACTIVITY has been
introduced. You will learn this in detail as you proceed.
You can note here that the Arrangement values are stored with Arrangement ID
and the Property ID and the Arrangement date. Though the Application storing
Arrangement values is based on Property Class, the records are maintained by
Property ID. This is because at an Arrangement level there could be multiple
Properties for a Property Class. For example, PRINCIPALINT and
PENALTYINT Properties for the INTEREST Property Class.

T3AAC - R12.1 131
Adding a local reference to a property means it has to be replicated across all of
these files. To avoid duplicating the same set of fields across 4 files and also to
maintain data integrity, AA allows definition of Local reference fields to just one
file (the PRD.DES file) and replicates the same across other levels
automatically.
Designer (Example : AA.PRD.DES.CUSTOMER)
Catalog (Example: AA.PRD.CAT.CUSTOMER)
Arrangement (Example: AA.ARR.CUSTOMER)
The local reference field is defined in the application LOCAL.TABLE, then
added to the local ref table of the desired property class’s designer table. When
the local ref table is authorised for the designer, standard selection records of the
property’s proof, catalog and arrangement files are rebuilt along with the
designer record.

T3AAC - R12.1 132
T3AAC - R12.1 133
Activities are operations that can be applied to Arrangements
Example : Disburse, 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

T3AAC - R12.1 134
Anything you do that affects an Arrangement is done using an Activity.
Activities are business functions which can be invoked directly by a user or
through close of business processing or via another application like Funds
Transfer or Teller.
Activities include creating an Arrangement as we have seen, disburse loan,

accrue interest, make a repayment, etc. The only things that are not Activities
are enquiries of one kind or another, where you are just looking at details and
not changing anything to do with an Arrangement.

T3AAC - R12.1 135
Now we have an idea of what Activities are, let us see how they work in AA.
In AA, Activities are associated with Properties. A crucial point to note is that,
few activities like ‘Create New’ , ‘View arrangement’, ‘Takeover activity’ acts
on the arrangement. This is the only exception to the rule.
In this Arrangement, we have the Property COMMITMENT of the

TERM.AMOUNT Property Class which define the Term and Amount. Similarly
REPAYMENT Property is associated with the PAYMENT.RULES Property
Class, which defines how a payment of a Loan is to be applied to various dues.
Finally PRININT property is associated with INTEREST Property Class which
defines the rate, margin, etc. for Interest.
Here, disbursing a loan is naturally associated with the Commitment Property

which will affect the Amount of the loan; an accrual is naturally associated with
the Principal Interest Property, and apply payment is related to Repayment
Property and so on.

T3AAC - R12.1 136
Activities are defined within a Product Line. Although Properties can be shared
between Product Lines, Activities are not. Activities represent real behaviour of
the system, and this may be intentionally different across Product Lines.
Properties can have multiple activities associated with them. The Activities
associated with the Commitment Property (of TERM.AMOUNT Class) include
disburse funds, increase committed amount, change term, etc.
We define another term, the “Process”, which represents what is actually being
done by the activity.

T3AAC - R12.1 137
This example explains how activity is associated to a Product Line, a Process
and a Property
Here the process DISBURSE related to LENDING Product Line acts on the
Property: COMMITMENT and the Activity is LENDING-DISBURSE-
COMMITMENT i.e. The amount of the loan is disbursed.

T3AAC - R12.1 138
Similar to the Properties are named types of Property Classes, we have
Activities belong to Activity Classes.
While Activity Class is related to a Property Class, an Activity is related to a
Property.
For example, take Activity Class LENDING-DISBURSE-TERM.AMOUNT.
The ID is a combination of Product Line–Process-Property Class.
The related Activity will have an ID with a combination of Product Line-
Process-Property, where the Property is linked to the Property Class. In this
case, where COMMITMENT is a Property linked to the Property Class:
TERM.AMOUNT, the corresponding Activity ID will be LENDING-
DISBURSE-COMMITMENT.
Normally Activities are generated automatically when you modify a Product
Group and request the Activities to be rebuilt. Here you can see the Activity
LENDING-DISBURSE-COMMITMENT under the Activity Class LENDING-
DISBURSE-TERM.AMOUNT. Here COMMITMENT is a Property belonging
to the Property Class: TERM.AMOUNT and attached to a Product Group under
the LENDING Product Line.
System generates AA. ACTIVITY records for each of the property when used
for the first time in a Product Group when the product group is set with
REBUILD.ACTIVITIES Field to YES.

T3AAC - R12.1 139
Normally Activities are generated automatically when you create or modify a
Product Group and request the Activities to be rebuilt. This does not create user-
friendly descriptions for the activities. It is recommended to modify the activity
descriptions once all the Properties have been generated.
For each ACTIVITY.CLASS of TERM.AMOUNT Property Class, a
corresponding ACTIVITY record for its property, say COMMITMENT can be
created.
An Activity is automatically created when a Property is added to a Product
Group with Rebuild Activity set to yes.This process creates all the standard
Activities for each Property. Meaning,
1. Picks up all the Properties for the Product Group
2. For each of the Properties, gets the appropriate Property Class name
3. For each of the Property Classes, gets the appropriate Activity Class name
4. Based on the Activity class, builds the Activities.

T3AAC - R12.1 140
Now, take a look at the Activity Class LENDING-ACCRUE-INTEREST. This
is where all the logic is built. Look at the Action tab. When this Activity is
performed, this Action tab tells us what are the various actions that will happen
in the background. Normally, in the traditional approach, when you wish to
accrue interest, you would have written code for - a. Actually accruing the
interest; b. Checking to see if any restrictions to interest has been made in any of
the parameter tables; c. Calculate charges if any and d. Send delivery message if
required. The most crucial thing to remember is, you would have done this for
all applications that need to calculate interest.
In AA, when LENDING-ACCRUE-INTEREST activity is performed, the
following will happen – a. An action ACCRUE will be performed on the
INTEREST property class; b. An action EVALUATE will be performed on the
ACTIVITY.RESTRICTION Property Class; c. An action CALCULATE will be
performed on the ACTIVITY.CHARGES Property Class and d. An action
SEND.MESSAGE will be performed on the ACTIVITY.MESSAGING Property
Class. Now, what do these actions mean. These actions denote that, internally,
T24 will invoke ‘action routines’ to actually perform the job. For instance for
action ACCRUE on the INTEREST Property Class, a routine named
‘AA.INTEREST.ACCRUE’. The naming convention is AA.<Property class
name>.<Action>. These action routines are available and can be reused.

T3AAC - R12.1 141
To understand usage of activity type concept better, let us look at Activity Class
definition LENDING-DECREASE-TERM.AMOUNT.
When you view the list of Activities that you can perform on an Arrangement,
all Activities belonging to a particular Property Class (TERM.AMOUNT in this
case) will be displayed provided, ‘User’ is set in TYPE Field in Activity Class.
In this case, please note that “Decrease Activity for Commitment” is displayed
against Term Amount in the Arrangement. This is the Description of the
Activity: LENDING-DECREASE-COMMITMENT. Please note that in this
Arrangement, the Property COMMITMENT is linked to the TERM.AMOUNT
Property Class and hence the corresponding Activity is allowed for User
execution.

T3AAC - R12.1 142
There are five ways to do an arrangement activity.
They can be run directly from the Arrangement Overview for changing terms
and conditions like the loan term, interest changes, basically changing any of the
product conditions for the loan.
They can be run indirectly via a transaction. These are typically the financial
activities, disbursements, payments, etc which affect balances.
They can be run as part of COB (Close of Business). This includes interest
accruals, bill processing, etc.
They can be run from another system using an OFS message
They can be run as a “secondary activity”, triggered from another activity

T3AAC - R12.1 143
Activity Log maintains a record of all activities performed in an arrangement.
The record is in a chronological order. User can drill down to view the details of
the activity. Activity log is used as a basic information tool for reversal of
activities.
The Activity Log shows all Activities relating to the Arrangement. The most
recent Activity is shown at the top on the grounds that it is likely to be the most
relevant. In this example we see the New Arrangement, issue bill, made due and
Decrease commitment amount activity.
Activity log hold the status of the Activity whether authorised, unauthorised,
reversed or reversed unauthorised.

T3AAC - R12.1 144
When you run a transaction against an Arrangement, T24 behaves in a different
way from if you had run the same kind of transaction against an ordinary T24
account. The system automatically invokes the appropriate Activity for that
transaction.
This works 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. You will learn how to configure these in the AA
business course.

T3AAC - R12.1 145
Select the Lending arrangement created in earlier Workshop.
Disburse USD 50,000 to Customer’s account in USD.
Approve Overrides, Get the record authorised.
Look at the activity log.

T3AAC - R12.1 146
The Lending arrangement created in earlier Workshop is selected and an
amount of USD 50,000 is disbursed to Customer’s account in USD.
Overrides are accepted, and the record is authorised.
Activity log of the arrangement after disbursement is displayed.

T3AAC - R12.1 147
Select the deposit arrangement created in earlier Workshop, Fund an
amount of USD 400,000.
Approve Overrides, if any and get the record authorised.
View the Activity log.

T3AAC - R12.1 148
The Deposit arrangement created in earlier Workshop is selected and an
amount of USD 75,000 is funded.
Overrides, if any are accepted, and the record is authorised.
Activity log of the arrangement after funding is displayed.

T3AAC - R12.1 149
Reversal and replay is enabled for products when LINE.ATTRIBUTE Field in
its AA.PRODUCT.LINE is set to REPLAY.
Financial Position and related calculations are based on value date. Reverses all
related activities backwards from today to back valued date. Current back
valued entry is triggered. Replays activities from back date to today. Accounting
entries are passed for both reversal and replay. Full History of the arrangement
conditions should be available for reversal and replay activities.
The correction processing takes place in real-time and is initiated by the
submission of a back-dated arrangement activity.

T3AAC - R10.2 150
Reversal and replay is enabled for products when LINE.ATTRIBUTE Field in
its AA.PRODUCT.LINE is set to REPLAY.
Financial Position and related calculations are based on value date. Reverses all
related activities backwards from today to back valued date. Current back
valued entry is triggered. Full History of the arrangement conditions should be
available for reversal and replay activities.
Activity class field TYPE determines how the activity should behave during
reverse and replay.
Reversal of activity not possible when AA.ACTIVITY.CLASS type is
NOREVERSE. Activity cannot be manually reversed by user.
Replay of activity not possible when AA.ACTIVITY.CLASS type is
NOREPLAY. Activity will not be reversed / replayed by any activity. Activity
will not trigger reversal / replay of other activities when AA.ACTIVITY.CLASS
type is NORR.

T3AAC - R12.1 151
Whenever an Arrangement is created under the Lending, Accounts and Deposits
Product Line, an Account is created for each Arrangement. The Arrangement
thus created, along with its Account and Balances belong to the Company under
which it was created. It is possible for the USER to change the Company to
which the ARRANGEMENT belongs to through the application
EB.COMPANY.CHANGE.
Both these companies should share the same financial files in the database for
the change to happen.The actual process of company change happens during
COB.

T3AAC - R12.1 152
The User, in order to use the alerts features, has to make the ALERTS property
class part of the PRODUCT.GROUP and add the relevant property to the
PRODUCT.
The product condition created for this property class will contain the event
(Activity) for which the Alert has to be triggered. All other parameters for
triggering the Alert will be set up as part of the Alert processing system.
Once the product condition has been created and added to the product, user has
to trigger the activity for which this alert has been setup (which is
LENDING-DISBURSE-COMMITMENT). The disbursement activity will
in turn trigger the LENDING-SUBSCRIBE-MYALERTS activity which will
create the alerts for the event. Once this activity has been authorised, a
record will be created in AA.ARR.ALERTS application.

T3AAC - R12.1 153
Activity Presentations class is used for defining various versions to be used for
different Property Classes / Properties / Activities during an arrangement
entry. It helps in displaying various versions / screen while inputting an
arrangement through browser for different Properties of the product.
SUPPRESS.SEE.MODE - If the user wants to view only the property and its
fields relevant to his activity that he is inputting and suppress all other
properties that open up in SEE mode (non-editable), user has to set this field
to "YES". Default option for this field is NULL. If the field is set to NULL,
all properties along with its field values would be shown during input of an
activity.

T3AAC - R12.1 154
T3AAC - R12.1 155
AA provides a Simulation tool which can help in decision making for the
customer.
• Creates simulated loans for prospective and existing customers.
• Performs what-if speculation for new loans.
• Calculates loan duration, when amount and installments are given. Similarly,
amount or installment can be calculated when other two variables are given.
• Simulates multiple disbursements within the loan schedule.
• Possible to convert simulated loan into a live loan.
• Shows 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.
You have learnt earlier that data of an arrangement are stored in respective
Property Class records AA.ARR.<PROPERTY.CLASS>. Similarly data of
simulated arrangements are stored in AA.SIM.<PROPERTY.CLASS>.

T3AAC - R12.1 156
AA Simulation can be run for future dated activities. We can also simulate a set
of activities for a specific period, where a start date and end date is given.
More than one activity can be simulated simultaneously.
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 user-defined days and
if the customer opts for the same, it can be executed into a live record.
Simulation also performs activities on existing arrangements for situations like
what if, pay off or renewal on a specified date.

T3AAC - R12.1 157
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 condition of the product.
The data captured in simulation capture are stored in
AA.SIM.<PROPERTY.CLASS>.
Simulation runner is used to define the period of simulation and list of activities
to be simulated. This runs the data captured through the Simulation data capture.
Before simulating an activity, Simulation service has to be started.

T3AAC - R12.1 158
AA.ARRANGEMENT.ACTIVITY application is used to trigger activities for
live arrangement. AA.SIMULATION.CAPTURE application is used to trigger
simulation.
AA.SIMULATION.CAPTURE application has same set of Fields as that of
AA.ARRANGEMENT.ACTIVITY.
All defaulted and negotiated conditions captured through
AA.SIMULATION.CAPTURE application are stored in individual SIM files for
each property like AA.SIM.INTEREST, AA.SIM.CUSTOMER, and
AA.SIM.TERM.AMOUNT etc.
AA.SIMULATION.CAPTURE application can be used to capture, simulate and
directly execute the required activity.
When Field AUTO.RUN is set to EXECUTE, data captured are executed into a
live file.

T3AAC - R12.1 159
AA.SIMULATION.RUNNER is mandatory for simulating the captured
information. When the AUTO.RUN Field is set to SIMULATE,
AA.SIMULATION.RUNNER record is created automatically during
committing of AA.SIMULATION.CAPTURE. If this field is set to NULL,
AA.SIMULATION.RUNNER will not be created automatically. In this case,
User should create AA.SIMULATION.RUNNER.
SIM.CURRENCY Field is defaulted with Currency of Simulation Arrangement.
SIM.RUN.DATE, SIM.END.DATE Fields are defaulted with system date and
user can change the end date to define a simulation period. If the
SIM.END.DATE Field is left Null, system will run the simulation only for the
run date.

T3AAC - R12.1 160
The user can opt to have a simulated arrangement converted into a LIVE
arrangement based on the customer’s final decision.
This can be achieved by setting the field EXECUTE.SIMULATION in
AA.SIMULATION.RUNNER to ‘YES’.
User can set to simulate associated or related activity along with a simulated
activity. For example, what-if speculation for creating and disbursing an
arrangement; repayment and make due activities etc.
Associated activity is defined in RELATED.ACTIVITY Field of
AA.ACTIVITY.

T3AAC - R12.1 161
After the basic information for simulation has been captured, next step is to
actually run the simulation. AA.SIMULATION.RUNNER application is used to
run the simulation from a given start date to end date.
The service AA.SIMULATION.SERVICE simulates the activity given in
AA.SIMULATION.CAPTURE. The service can be set in AUTO mode and the
respective agents started. If the service AA.SIMULATION.SERVICE is in STOP
status, message for simulation will not be picked up. Hence no simulation will
take place.
Simulation monitor refreshes every 10 seconds to check the status.
STATUS Field denotes the status of the simulation runner. It is a non-input
field.
COMPLETED - SUCCESSFULLY -> This denotes that runner has been
completed successfully.
COMPLETED - ERROR -> This denotes that runner is completed but has got
errors while executing.
Processing -> This denotes that runner is getting executed.

T3AAC - R12.1 162
The pre-requisites for starting a simulation is detailed here.

T3AAC - R12.1 163
Simulate an arrangement for your customer effective today, Loan
amount is USD 5,00,000 for 3 years
Commit the record. View your simulated arrangement.

T3AAC - R12.1 164
The simulated arrangement is input with details under Commitment tab,
committed.

T3AAC - R12.1
The simulation runner starts and shows the status monitor. Once the status is
shown as Completed – successfully, the simulated arrangement overview is
accessed and viewed.
Please note that to view the simulated arrangement overview, either menu
navigation as mentioned in workshop contents can be done or the icon next to
Status completed successfully can be clicked.

T3AAC - R12.1
1. c
2. b
3. b

T3AAC - R12.1 167
The AA module provides a flexible framework that allows a number of new T24
modules to be created. The application provides a business component based
architecture for the management of products.
The application provides the ability to allow the user to construct banking
products by combining different business components. PRODUCT.LINES
which provide functionality for different banking areas are licensed by Temenos;
each product line utilises a number of property classes (business components)
that are fully configurable.
Main features of the product builder are:
• Ability to build families of products.
• Ability to inherit properties from the product family structure.
• Ability to determine the properties that a product is comprised of.
• Control of default values to be applied for product arrangements.
• Dated conditions for products.
• Full control of scope of negotiation between product and arrangement
conditions.
• Control of negotiation of attributes over time.
• Design/Proof/Publish lifecycle for product management.
• The product builder can be used to create and maintain existing application

T3AAC - R12.1 168
(Mortgage, Account, Loans and Deposits and AZ) product parameters.

T3AAC - R12.1 168
T3AAC - R12.1 169

T3TAAC - Arrangement Architecture - Core-R13.2

Uploaded by

Copyright:

Available Formats

T3TAAC - Arrangement Architecture - Core-R13.2

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

T3TAAC - Arrangement Architecture - Core-R13.2

Uploaded by

Copyright:

Available Formats

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

Thus a Component has common Attributes and Actions across different

In AA we refer to these Components which have Attributes and Actions as a

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

A Product Group is a sub-set of the Property Classes of its Product Line. Of

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

A Product is where the Properties are linked to Product Conditions. As economic

T24 Arrangement Architecture - Core -

To summarise, the PROPERTY.CLASS definitions are released by Temenos and

Every Product Line is a composition of multiple Property Classes, some of

Finally a Product is a saleable unit, attached to a Product Group. It is in a

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

Creating an Arrangement involves “negotiating” with the Customer for changes

Technically an Arrangement is created with a copy of the Product Conditions,

You will learn about what is negotiation in the next page.

T24 Arrangement Architecture - Core -

An arrangement is Customer specific offering of a Product. An Arrangement is

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -

T24 Arrangement Architecture - Core -