T3TAAC Arrangement Architecture Core R14 PDF

Arrangement Architecture - Core - T3AAC - R14 1
The AA module provides a flexible framework that allows a number of products

to be created. It allows the 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 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. We will understand the link between a product and an arrangement and
arrangement and activities.
AA also provides for simulation - “what-if” analysis for new and existing product
instances without creating or affecting live records.
AA also has mechanism to input a back dated activity and keep the system up-
to-date without running COB
It is possible to have variations in a single product based on channel, customer

segment or similar variations which is dealt as part of Product Variations.

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 offer new products to
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.

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.

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 banks can create their own Products
using the Components provided by Temenos. These components can be reused
across many Products.

In AA there is a three tiered Product Organisation comprising of Product Lines
defined by Temenos. Product Groups and Products are defined by banks.
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.

Product design and servicing are enterprise level functions. Functionality is
encapsulated in a set of common product components. Each component has
attributes and actions defined by Temenos.

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…….

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.

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, budget, etc. of customers. This further helps customers
to get the product modified later with their choice. For example, a customer
can select a car with standard alloy wheels and later get the wheels changed
with spokes or radial ones. Financial institutions would like to have the same
flexibility and ease of designing and selling Products.

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.

T24 distinguishes its business applications as Account based or Contract based.
This comes from the underlying business of Banks which allow balances in
accounts to switch from positive to negative sign. On the other hand a loan
always remains a loan and a deposit for a fixed period always a deposit till its
maturity. Balances in these contracts never switch their 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 have an underlying T24 Account and balances in these can be
both positive or negative.

T24 Customer
Create an arrangement for Current Account product under Current Account

group. Commit the Arrangement and get it authorised.

T24 Financial Accounting
Use the menu path displayed to create a current account arrangement.

Input customer ID and currency of arrangement and validate the record. Note
that on creation of the new Arrangement we have an ID starting with AAACT.
This is the activity ID for creation of this arrangement. We will discuss about
Activity in detail later during this course.
On validating the record the we can see the components of the arrangement as
hyperlinks for eg Customer, Account officer, Debit Interest Credit Interest. We
will see later how the default values appear in these components, whether the
values can be amended and if so, what are the limitations.
You may note that under the Account tab, the Account number associated with
this arrangement can be seen.
Now, commit the record.

To authorise the authorise the arrangement, follow the screen shots given
above.

The arrangement is now authorised.

Now view the arrangement and identify the components of the arrangement
account.

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.

The Components for vehicles and Banking products are shown above.
Components for a vehicle are Engine, transmission lines, Wheels, Body style
etc. For a banking product like Loans, the components are Term Amount,
payment Schedule, Interest, Charges
In AA, Attributes and Actions are defined for every Property Class(component)
by Temenos

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 will have different values.
For example, in the case of a Car, the component Wheel has two instances
Front Wheel and Rear Wheel. Both, 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 PRINCIPALINT and PENALTYINT are instances of the Interest

Property Class. But they can 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, banks can create new Properties based on Property Classes, Property
Classes can be created only by Temenos.

In a Product, we can have any number of Properties derived from a Property
Class, but the attributes of all such Properties are the same as that of the
Property Class. They have the same Attributes and the same actions. However,
their Attributes can have different values as explained earlier. It is the Property
rather than the Property Classes, which is used to define the Products

Banks can create required Product Groups under Product Line. Product Line,
which is a combination of Property Classes is defined by Temenos.
A Product Group is made up of a sub-set of the Property Classes of its Product

Line. Of course, all the mandatory Property Classes must be retained in the
Product Group and optional Property Classes may be included or omitted.
Further, at the Product Group level, we must specify the Property (at least one)
for each Property Class.

For example, a Product Line has 3 Property Classes: Account and Interest are
mandatory and Charges is 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 we have two Properties - Principal Interest and Penalty Interest as

properties of the Interest Property class

Under each Product Group, multiple Products can be created by banks. It is
finally the Products which a Bank can offer to its Customers.

A Product Condition defines the default values for its Attributes. It is also used
to define Negotiation Rules that specify if the default values can be modified.

Product Conditions are linked to Property at Product level. As economic and
processing conditions may change over time, clients can optionally set an
effective date for such conditions.

In AA, Property Classes and Product Lines have been defined by Temenos.
Financial institutions can use these “building blocks” to construct Products
which can be sold to their customers.
To summarise, PROPERTY.CLASS definitions are released by Temenos
Every Property Class has features called attributes. Product Conditions are used
to define default values for the Attributes of a Property Class and certain
processing rules.
A Property is a named instance of a Property Class. Properties can be created as

required by the banks
Every Product Line is made of multiple Property Classes, some of which can be
set as Mandatory by Temenos. Clients can create Product Groups under a
Product Line by specifying the Property for every Property Class.
Finally a Product is a saleable unit, created under a Product Group. In the
Product we link the Product Conditions to Properties.

Answers:
1. a
2. b
3. a

4. a
5. b
6. a

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 does this mean? 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 as 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

Earlier you have seen how a Car Product can be designed using inheritance and
Product hierarchy. Now you will see 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 then bank with Property Classes from the Lending Product Line. We must
also define the Properties for the Property Classes and specify 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 see in the next few slides how a Product can be defined under this
Product Group. System will ensure that each mandatory Property Class of the
Product Line has at least one Property defined in the Product level.

Clients can create Product Conditions for every Property Class and then attach it
to the Property at 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 COMMITMENT Property at Product Level.

In the above example, we have 5 Product Conditions for the
PAYMENT.SCHEDULE Property Class. In the Product Group, for the
PAYMENT.SCHEDULE Property Class, the REPAYMENT.SCHEDULE Property is
used and the Product Condition (Constant Monthly) is attached to the Property
Repayment Schedule.

For PAYMENT.RULES property class, two Properties REPAYMENT and
PRINCIPAL.DECREASE are available in the Product Group. One of the four
available Product Conditions of PAYMENT.RULES Property Class is attached to
each of its associated Properties at Product Level.

The only Product Condition created for ACCOUNTING Property Class is attached
to its associated Property at Product Level.

A product is created when Product Conditions are associated to respective
Property

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 level products
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 if Product Conditions are 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 parent. 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 parent.
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.

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 few slides.
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.

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, 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.

1. a
2. b
3. c

AA Product Builder can be used to construct AA Products and publish them into
a single product Catalog.
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.
“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 Products are made available for sale to Customers by including them in
Catalog.

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 in a single Catalog
through Arrangement Architecture (AA).
AA has its own set of products, like AA Loans and AA Deposits which can 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 T24 VERSION for easy access.

In product builder, the first step is to have broad product lines. These are pre
defined by Temenos. Product Lines namely Lending, Deposits, Accounts,
Bundle, Relationship pricing are dealt under Retail. The other product lines are
Internet Services, Mobile Services, Proxy Services and Others.
From product line, we move to product groups - AA.PRODUCT.GROUP. Product
Groups are created under product lines. Property classes have been defined for
each Product Line. When creating a PRODUCT.GROUP, all mandatory property
classes from PRODUCT.LINE must be included. Optional property classes from
PRODUCT.LINE may/may not be included. At PRODUCT.GROUP level, we must
specify the property that will be associated with each Property.class

AA.PRODUCT.DESIGNER application is used to define products.
Under a Lending product line, for a product group called PERSONAL.LOANS, we
can define any number of products.
After designing the product, it must be added to Catalog. This is a two step
process. When the product is designed as part of a product hierarchy, T24 does
not check whether all properties have been defined . However, when the
product is subject to proof, its conditions, accounting rules and calculation
sources are validated. If all these are mapped correctly, then proofing is
successful. After that, product has to be published to add it to Catalog.

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

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 Clients to change description of these product lines as they desire.
This could be achieved by amending the existing description.

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.

By using the icon for Drilling down to instances, Clients 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.

You have learnt earlier that Property Class is the 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.

Property Classes are building blocks, released by Temenos and you can only
amend their Description.
Financial institution use the functionality of “building blocks” to construct
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 – This option indicates that the property class has special merging

properties when doing proofing and publishing. The child condition does not override
the parent condition blindly as other classes do.

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 - This option behaves much like TRACKING.ONLY type, except
that the property conditions will be allowed to be amended at the arrangement
level subject to negotiation rules. So, when a property class is defined with this
type, then, any activity done at arrangement for the property of this class will
always see the product and default them in the arrangement condition. This
option indicates that the property of this class has some special arrangement
level processing, hence, the field values at the arrangement level will not be
merged with any of the previously amended arrangement values. Currently,
only BALANCE.MAINTENANCE is defined of this type.
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: From R14, If a Property Class is of type Variation, an additional
component will be seen in the Product condition ID
Variations enable variations in a single product. Meaning a single product for
preferential pricing strategies. This mechanism makes use of different
conditions (i.e. it has multiple variations) based on characteristics such as
channel and or customer. The variety of a product a customer receives is
dependent on both eligibility and a priority order (where the client is eligible for
multiple variations).
Prior to creating products with variations, the “named” variations are to be
defined. These will be used in both the product designer (to specify a priority)
and within the ID of the product conditions.
Variations are defined in the virtual table AA.PRODUCT.VARIATION.
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 through various channels.

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.

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 Lines will be affected.

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.

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 must have balance types defined
before using it in Product Group and Product.

In AA we can create named types (instances) of a Property Class known as
Property. Properties are stored in AA.PROPERTY. Multiple properties can be
attached in a product if property class type is MULTIPLE.
PROPERTY.TYPE: can have one of the following values Product Only, Suspend,
Suspend Overdues, Variation, Residual accrual, Credit, Forward dated, Accrual
by Bills. PROPERTY.TYPE may also be Null

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.
VARIATION: Although Temenos defines the AA.PROPERTY.CLASS type as

variation another step to configure is to flag the AA.PROPERTY record also as
variation. A property of a Property Class that is of type variation can be defined
to be or not be of type variation. If a product condition with variation
component in ID is defined for a property that is not of type variation, error will
be raised during Proofing

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.BILLS will be called after normal
accrual process is completed to update bill details, with accrual corresponding
to that bill.
BLANK indicates that it is a normal property, there are no special features

Create new property for Customer Property Class

Input property name 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.

We now know how to create a Property. It is the Product Condition which is
used in a Product to default values in an Arrangement and to control their
modification.

What is the underlying application that is used to store all Product conditions?
Product Conditions are associated with 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 there is an application named AA.PRD.DES.<Property

class name>.
You will see an example for this in the next page.

Product condition can be currency-specific. You may notice that in the
TERM.AMOUNT Product Condition USD is part of Id.
If Property classes has TYPE set to CCY then Product condition will be currency
specific. For such Classes, Products that support multiple currencies will require
Product conditions for each currency. Product Conditions that are not currency
specific just have one condition, and currency will not be part of ID.
For example we have a Product Condition called FIXED.INTEREST-USD. If
product is available in 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 in currency of arrangement will be used.
Property class TYPE = CCY - Specifies whether Properties created for a Property
Class 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, product
condition will NOT be based on currency.
Property TYPE = DATED - Specifies whether Properties created for a Property
Class can have dated Product Conditions or not. If this field contains DATED
then Product conditions vary by date and relevant dated product condition will
be used when processing. Product Condition will contain an effective date in

record key. All property classes are of type DATED

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.

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. 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.
Product can be created with current and future dated Product Conditions.
Product 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 current date.

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.

To create variations of a product, first create Product Conditions for each
property that is specified as having a variation.
INTEREST Property class is currency specific and dated. When the variation
product condition is for the variation Branch, the product condition ID is:
FIXEDRATE-USD-BRANCH-20100806
ACTIVITY.CHARGES Property class is dated and when the product condition is

created for the Branch variation, the product condition ID is:
VEHICLE.LOAN-BRANCH-20100101
If the AA.PROPERTY.CLASS type is defined as “Variation” then the ID of the

product condition will have one additional component, which will accept a
value defined in the virtual table.
When a key is defined in AA.PRD.DES.XXX for a property class which supports

variation, validation is done to check whether it is a valid variation defined in
AA.PRODUCT.VARIATION virtual table and error will be raised otherwise

To summarise, the currency and effective date of a Condition are part product
Condition ID. 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.

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 next few slides

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 customers have the
flexibility 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 negotiation rules on the Term Amount
property for the AMOUNT attribute.

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

Negotiation Rules tab
Field: DEFAULT.NEGOTIABLE is a Mandatory field with options Yes /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
attributes 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.

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
Resetting
NonResetting

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.

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.

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.

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.

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.
The top level default attribute option can be modified at attribute level using
the drop down in NR.OPTIONS

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 25000, 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.

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

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.

1. b
2. c
3. b

Controlling Attribute values of an Arrangement over a period of time is done by
Periodic Rules, which in turn depends on Periodic Attributes.
Periodic Attribute Class Predefined periodic attribute classes are released by
TEMENOS to define Actions and Attributes for certain Property Classes
Clients are also allowed to create periodic attribute class from R13.
A Periodic Attribute can act on the Attributes of a specified Property Class.
Periodic Attributes can be defined by Clients 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.
Periodic Attribute
Named type / instance of a Periodic Attribute Class
Helps in controlling Attribute values of an Arrangement over a period of time

A Periodic Attribute is defined by Client from an existing Temenos or User defined
Periodic Attribute Class

We can see the Periodic Attribute Class defined for every Property Class
For each Periodic Attribute Class we have some predefined Periodic Attribute.

Let us use the Term amount product condition created in the earlier workshop.
We have to update the Periodic attribute AMOUNT.INCREASE.1Y indicating
amount increasing every year should not exceed the value of 10000.
If this condition is broken, override should be generated

Let us use the Term amount product condition created in the earlier workshop.
We have to update the Periodic attribute AMOUNT.INCREASE.1Y indicating
amount increasing every year should not exceed the value of 10000.
If this condition is broken, override should be generated
Charge levied on breaking the rule is optional.

You have learnt earlier that a Property Class is a fundamental building block of
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.

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

The Product Line provides a high level definition of the business components
(Property Classes) that may be required to construct a product belonging to
that line. For example the LENDING Product Line will enable users to design and
service term loan products such as Loans (personal, small business, etc.)
Mortgages Lines of Credit
The Product Lines are defined by Temenos and cannot be created by the User. A
Product Line is described by the Property Classes which constitute it. The
financial institution may then use these “building blocks” of functionality to
construct the individual products which are available for sale to its customers.
LINE.ATTRIBUTE: This optional field is used to specify whether the product line
deals with amounts/currencies and 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

LINE.ATTRIBUTE as REPLAY, supports reverse and replay mechanism.

Single
In order to give preferential treatment for each of the Relationship Pricing
Plans a customer can have only one arrangement (Among Gold, Silver and
Bronze, based on the eligibility condition, relationship pricing arrangement can
be formed for only one either Gold or Silver or Bronze).
The line attribute single indicates that there can be only one unique
arrangement for each customer for products belonging to this line. A customer
may take as many LENDING products that he may require – but there can be
only one RELATIONSHIP.PRICING arrangement for a customer.
Validations are added whilst creating NEW arrangement to raise error when
multiple arrangements are created under a single product.
Property Classes that constitute the line are marked as Mandatory or not. For a
mandatory Property Class, there should be at least 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

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

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.

Under the Property Classes tab of Accounts Product Line, these are the valid
Property classes.
Please note that whether the Property class is mandatory or not is also
indicated here.

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. Clients 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. Each
Product must belong to a Product Group.
GROUP.TYPE Field : Valid options are INTERNAL and EXTERNAL
INTERNAL – means the group being defined is for 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
products(INTERNAL) and products of its competitors. Those groups may be
defined as EXTERNAL. These products may then be used for comparative
analysis to show the superiority of Bank's product. Products of this type are not
available for sale to customers.
REBUILD.ACTIVITIES field is used to rebuild AA.ACTIVITY records from
AA.ACTIVITY.CLASS. AA.ACTIVITY for all instances(properties)of class(property
class) are created. This can be used to rebuild activities when a new property is
introduced into a group.
We will discuss about AA Activities later in the course.

Create a new Product Group with the Property classes and properties as given
above.

A new Product Group is created under Lending Product Line with appropriate
inputs in Property class, Property and Mandatory fields as given in the
workshop.

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.

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.

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 effect on the existing arrangements. The
three options are TRACKING, NON-TRACKING and CUSTOM.TRACKING

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.

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.

For a product that should have variations, we must specify which variations are
required and whether there is a default product if a customer does not qualify
for any variation.
In the PROPERTY.VARIATION field of the product designer, the user could select
which variation it should support. Also, if a customer is eligible for more than
one variation, then the variation to be used would be determined based on the
priority defined in the variation tab.
If a product is defined with 2 variations - Gold and Silver then (eligibility

conditions given for both GOLD and SILVER), if a customer is eligible for more
than one variation, priority defined will determine which variation will be used.
Please note that , eligibility conditions can also be configured for a “default”
product if required.

Property Variation
Definition is allowed only for the Properties of a Property Class for which
variations are defined. If the product supports multiple variations, then product
conditions needs to be created for each variation. In the PROPERTY.VARIATION
field of the product designer, the user could select which variation it should
support. Additionally, if a customer is eligible for more than one variation, then
the variation to be used would be determined based on the priority defined in
the variation tab.
When variation is attached to a property at product designer but variation type
is not defined at property, a error message is displayed “Property not allowed
for variation”.
Variations and Priority
If a product has more than one variation, the user can specify the variations and
their priority order to be taken through this field. The available values are from
the virtual table AA.PRODUCT.VARIATION as previously defined. The order in
which the user specifies the variations is from top to bottom. In other words,
when determining the variation to use, the system would start from the first
multi-value field and stop when the customer is eligible.
Default Available
If the customer is not eligible for a variation, then this field would determine if
there is a “non-variation” (Default) product. If this is “checked” then the default
configuration could not have ELIGIBILITY, as all the customers would be eligible.

1. c
2. c
3. b

Create a Product under the Product Group created in the earlier workshop. At
least one product condition must be attached for each property. Set the
calculation source tab as indicated.

The product is created under the product Group defined earlier.
The properties from 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.

Product conditions are assigned for each property.
Calculation source is indicated for the interest property.

Create another Product under the Product Group created in the earlier
workshop. This product is set as INHERITANCE.ONLY as product definition is
incomplete. Only 6 out of 9 properties are defined in this product
At least one product condition must be attached to each property. Set the
calculation source tab as indicated. product is to be defined as a Parent

The properties from the product group are defaulted while creating the
product. We are creating a inheritance only product as only 6 out of 9
properties are defined. This product will also become the parent product. the
remaining properties will be defined in the child product. Suitable product
conditions are filled in, arrangement link is set for tracking / non-tracking.

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 attached to each property. Set the calculation source tab as
indicated.

We are creating a Child product. This product is the child of parent product
created earlier and is under the same product group. The properties from 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.

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

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

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

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

Catalog.

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
must 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. The Service– AA.PUBLISH.SERVICE processes this list file and
proofs/publish products.
Proofing always happens from parent down to child. Proofing the Parent
product automatically proofs all child products also

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.
Arrangements for the product can be created only from this date
Another date 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.

Proof the Parent Product used in the previous workshop with available date as
today, then publish the same.

The parent product is proofed online with available date as today. If proofing is
successful, status monitor shows the status as completed successfully. The
product is then published and status monitor shows the status. Only a product
that has been proofed successfully can be published

Answer:
1. c
2. b
3. b

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.

Create an arrangement for Mortgage product and set the following:
Create an Arrangement for Mortgage Product
Indicate a commitment amount of 50,000
Input a settlement account under Pay In and pay out settlement tab
Ensure that payment schedule has disbursement property % as 100%

Against DISBURSEMENT type bill
Commit the Arrangement, accept overrides and get it authorised

From R14, T24 Document Management can capture and upload (store) the
documents and images at arrangement level for loans, deposits and accounts
products in the Arrangement overview
Enquiry – AA.TXN.DOC is used for Viewing, Reversing, Editing and uploading the
Transaction documents. Also possible to upload/ reverse uploaded documents/
images as and when required using the Correspondence Tab
For instance the loan agreement obtained by the bank is available at
arrangement level in the arrangement overview screen in the Correspondence
tab (earlier named “Messages”).
DM.APPLICATION.INFO and DOC.GEN.CONDITION hold a record AAA. For the
DM.APPLICATION.INFO with record ID ‘AAA’ DOC.GEN.CONDITION specifies the
activities for which document management has to be set up.

An arrangement is created under Long Term Deposit product, picked from the
catalog.
Another owner is added to the primary customer.
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.

Now search for your deposit arrangement using the secondary customer
you have added in the arrangement.
You can find the deposit that we just created where this customer is a
secondary customer.

From R14,
Customer Relationship can define the percentage split of income/tax amongst
the primary and joint customer. Tax splits are calculated between the various
joint holders based on the tax types linked to them.
AA enables the tax calculation based on the customer relation for a customer
having a portfolio reference. T24 splits the tax calculated on an income for a
primary customer amongst the primary and joint customers in a pre-defined
percentage as indicated in the Customer Relationship.
ST.CUST.RELATIONSHIP.DATES - list of dates for a customer relationship record.

ID being customer relationship ID without the date
ST.TAX.REPORT.DETAILS - Tax report file to store customer-wise tax details

against a single transaction

Customer Relationship can be setup using CUSTOMER.REL.GROUP and
CUSTOMER.RELATIONSHIP (percentage share given here). Tax Type to have
Apply Split as yes and Tax parameter to be available.
CUSTOMER.RELATIONSHIP has to be indicated in the SEC.ACC.MASTER
(portfolio). The tax applicable for the arrangement is split between the owners
and splits are seen in ST.TAX.REPORT.DETAILS.

AA.ARRANGEMENT.ACTIVITY Application is used to trigger activities on
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>.

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.
On publishing a product, the respective product condition for each property is
stored in AA.PRD.CAT.<PROPERTY.CLASS>
The Arrangement values for the Property related to Customer Property Class
are stored in AA.ARR.CUSTOMER.
The ID of a record in AA.ARR.<PROPERTY.CLASS> is Arrangement Id-Property-

Date . serial number
On the same day if we have multiple changes in the same record, they are
stored as serial numbers of the same record (changes using Activities which will
be discussed later).
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.

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.

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.

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.

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.

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.

Properties are named types of Property Classes. Activities relate 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.

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.

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.

To understand activity , 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.

We can see that on triggering the Activity LENDING-ACCRUE-INTEREST, system
accrue interest and no user intervention is required. There are no other related
activities.
We see that in LENDING-INCREASE-TERM.AMOUNT we have increased the

commitment amount. This is a user input activity.
While we increase the commitment amount we may also update the payment
schedule. This is a secondary activity but will be triggered only on user input
Without any user intervention, system itself will trigger some activity to
evaluate if there any activity restrictions to increase commitment amount,
calculates any activity charges as result of increased commitment amount and
sends messages for increased commitment amount.

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

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.

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.
RC module is integrated with AA Framework and retry of unsuccessful

transactions is possible. The fields related to Retry are discussed in detail in the
advanced courses. For information about RC framework you may refer to the RC
userguide.

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 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.
Reversal happens unconditionally for all User, Transaction and Scheduled

activities
Replay would perform the User, Transaction activities on the dates on which
they were triggered
Replay of scheduled activities replay is decided at runtime based on the
backdated activity triggered at this instance

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

A Small business loan with Commitment 55,000 is chosen. It is disbursed
already and we can see that interest is accrued.

We see some User initiated activity and system triggered secondary activity in
AA.ACTIVITY.HISTORY. These activities are in AUTH status

On clicking the new activity tab we have list of activities,
Here choose to perform an activity, ensure the effective date is loan
commitment date and validate the deal.
We can see two tabs appear both Commitment and Schedule – Can you explain
why both the tabs are appearing based on what we learnt about activities
already?
Yes Payment Schedule update is a secondary user triggered activities based on
the Increase commitment activity.
When you increase the commitment amount and validate ensure to feed the
final amount to the Disbursal amount in schedule tab.
Now commit the record.

View the Activity history record and view the status. We can see Unauth,
Reverse
Do you know why some activities are reversed and why some are not reversed.

Authorize the record now

View the Activity history record. Observe the activities that are reverse
authorized or new activities that are created….. Now… in auth status

Ensure to choose an arrangement with value date earlier than current date.
View the Activity History of the Arrangement and look at the Authorised
Activities in it.

Ensure to choose an arrangement with value date earlier than current date.
View the Activity History of the Arrangement and look at the Authorised
Activities

Perform a backdated activity and commit the same.

In ACTIVITY.HISTORY we can see the a Reverse Activity and Unauth Activity, to
show the reversals and the new activity coming in.
Some activities are not reversed. Can you recollect why?

The activity is not deleted – Meaning the Reversal is Deleted

We can now see the Reversal Activity deleted and the new activity that was in
Unauth state Deleted.

We can see the Arrangement has an accrued interest for the rate 5% under
Prinicipalint component and amount is 230.13
Also we can notice that the Accruals are from 25 Mar to 31 Mar and then from
01 Apr to current system date.

We see the interest change activity is back dated and interest rate is changed,
In Unauth stage of this activity, there is no change in the
AA.INTEREST.ACCRUALS

Now the activity has to be authorised.
We can see the projected accrual change in the financial summary.

The accruals are updated in the AA.INTEREST.ACCRUALS.
We can see the activity for change in PRINCIPALINT is authorised and effect is
seen in the AA.INTEREST.ACCRUALS.
Can you recollect and explain why the Accruals are not seen in Activity history
and they are not reversed and replayed.
Observe the effective accrual amount is changed in interest is correct even
without reversal and replay.

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.

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.

ACTIVITY.PRESENTATION property class is used for defining various versions to
be used for different Property Classes / Properties / Activities during an
arrangement activity. It helps in associating various versions when
performing different activities related to different properties on the
arrangement.
SUPPRESS.SEE.MODE - If the user wants to view only the property and its fields
relevant to activity being performed 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 field values would be shown during input of an activity.

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

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.
In AA Lending, users can compare simulated arrangements or simulated
arrangement activities. Also, the users can print the comparison overview
screen if desired. A minimum of two simulations are required to compare the
values and a maximum of three simulations can be compared. Duplicates are
not allowed.
We will discuss further on this in AA Lending course.

Simulation 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.

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 or
directly execute the required activity.
When Field AUTO.RUN is set to EXECUTE, data captured are executed into live
file.

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.

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.

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.

The pre-requisites for starting a simulation is detailed here.

Simulate an arrangement for your customer effective today
Commit the record. View your simulated arrangement.

Status monitor is displayed after the AA.SIMULATION.RUNNER record is
authorised. When the status is shown as Completed – successfully, the
simulated arrangement overview can be viewed.
Please note that to view the simulated arrangement overview, either menu
navigation user Menu-> Retail Operations > Find Loan > New Offers can be used
or the icon next to Status Completed Successfully can be used.
The simulated Arrangement can be executed and bought to live status using the
execute icon in the Overview screen.

After the simulation is executed successfully, the arrangement can be seen
under Authorised arrangements tab

In the arrangement overview with the Simulations Tab, we can find the list of
simulations.
Out of these, the required records are chosen for comparison

Here, the Simulations chosen for comparison are displayed from
AA.SIMULATION.COMPARISON. On committing the record a pop up enquiry will
get displayed with the Drill down option. The simulation comparison result
appears with print option on the top.

1. c
2. b
3. b

Property Variation
Definition is allowed only for the Properties of a Property Class for which
variations are defined. If the product supports multiple variations, then product
conditions needs to be created for each variation. In the PROPERTY.VARIATION
field of the product designer, the user could select which variation it should
support. Additionally, if a customer is eligible for more than one variation, then
the variation to be used would be determined based on the priority defined in
the variation tab.
When variation is attached to a property at product designer but variation type
is not defined at property, a error message is displayed “Property not allowed
for variation”.
If a product has more than one variation, the user can specify the variations and
their priority order to be taken through this field. The available values are from
the virtual table AA.PRODUCT.VARIATION as previously defined. The order in
which the user specifies the variations is from top to bottom. In other words,
when determining the variation to use, the system would start from the first
multi-value field and stop when the customer is eligible.
Default Available
If the customer is not eligible for a variation, then this field would determine if
there is a “non-variation” (Default) product. If this is “checked” then the default
configuration could not have ELIGIBILITY, as all the customers would be eligible.

 If a VARIATION is stated, then one condition should exist for ALL
currencies from the date on which product is available.
 If a VARIATION is stated and the condition does not exist, an error
would be thrown during proofing stage.
 Even if VARIATION is stated and ALL variations for the product
condition exist, system will check for DEFAULT condition for all of
these properties. If default condition is missing, system will throw
error.
 When EFFECTIVE condition is stated (say FLOATING.INTEREST
condition after 1Y), then variation should exist for that conditions
as well.
 If a product supports MULTIPLE currencies, then variation
condition has to be available for all currencies.
 Eligibility condition needs to have all variation conditions, stated in
the VARIATION field , since this is the key property which
determines the variation itself.

Products are designed from Product Group Each Product must have all the mandatory
Properties and any of the optional Properties associated with its Group For each
Property, Product condition should also be defined
If a product has more than one variation, the user can specify the variations and their
priority order to be taken through this field. The available values are from the virtual
table AA.PRODUCT.VARIATION as previously defined. The order in which the user
specifies the variations is from top to bottom. In other words, when determining the
variation to use, the system would start from the first multi-value field and stop when
the customer is eligible.
Default Available
If the customer is not eligible for a variation, then this field would determine if there is
a “non-variation” (Default) product. Hence, a default condition (i.e. a condition with
no variation in the ID) must exist for every Property of the product if when a default
product is opted for. If this is “checked” then the default configuration could not have
ELIGIBILITY, as all the customers would be eligible.
Property Variation
Definition is allowed only for the Properties of a Property Class for which variations
are defined. If the product supports multiple variations, then product conditions needs
to be created for each variation. In the PROPERTY.VARIATION field of the product

designer, the user could select which variation it should support. Additionally, if a
customer is eligible for more than one variation, then the variation to be used would be
determined based on the priority defined in the variation tab.

Arrangements are created in the AA.ARRANGEMENT.ACTIVITY.
AA.SIMULATION.CAPTURE is used to capture information for simulation of new
arrangement.
A new field is introduced on AA.ARRANGEMENT.ACTIVITY and
AA.SIMULATION.CAPTURE that allows the system or user to specify the
Variation of the product.
When selecting a product from the catalog, on entering the customer number
and validating, AA should be configured to automatically choose the correct
variation based upon the eligibility rules and priority specified.
Note, if there is no direct relationship with the channel names and variations
defined in AA.PRODUCT.VARIATION, a local table can be used to update the
channel based on interface which can in turn be used to automatically choose
the variation.
Remember that if a variation is specified manually, eligibility is checked and if

the user is not eligible(error option) T24 raises an override, the user can choose
to accept the override with proper authorisation.

The AA.ARRANGEMENT table stores static details about an arrangement such
as Customer, Currency, Status, Product, Product Effective Date, etc. With the
addition of variations of products it stores the product variation (if there is one)
as well as the effective date. This information will form a sub-valued set of
fields that are part of the Product multi value set. In this way every time a
variation changes on an arrangement the information is recorded with the date.

We are aware of a separate product line Relationship Pricing which is used for
giving preferential rates to customers.
We also find channel-specific or nature-of-customer specific or customer-
segment specific rates are possible from Variations.
How do we differentiate from the usage of Relationship Pricing Product line and
Variations.
Variations are used to give a specific variation that correspond to the channel or
segment based on eligibility.
There are various situations in which the channel based or segment based rates
are required for the HNW Customers, Regular Customers, Loyal Customers and
Staff. A customer might be eligible for more than one relationship and the best
of them can be given and additional premium or discounts would be given
based on variation chosen.
You can learn about Relationship Pricing in detail in a separate course

In the EB.LOOKUP virtual table we can find the Branch, Internet and Mobile
records available for AA.PRODUCT.VARIATION.

The rules created in rules engine are seen under EB.RULES.VERSION

The property DEPOSITINT is setup to be Variation specific if it is not already
variation specific.
The Eligibility property is also verified if set up as variation specific.

Let us now view the predefined model bank product conditions for Eligibility in
each variation

Create model bank record for interest product condition in each channel

Product created has eligibility and interest property as variation specific and
their priority is set.
Remember, Default available is not defined.

Create arrangement under each eligibility and view the interest rate defaulted
based of channel eligibility

Remember, we have to set a default product condition for interest property.
What about Eligibility property? –No eligibility for default product.

1. True
2. False
3. False
4. False
5. False

6. False
7. false


T3TAAC Arrangement Architecture Core R14 PDF

Uploaded by

Copyright:

Available Formats

T3TAAC Arrangement Architecture Core R14 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

T3TAAC Arrangement Architecture Core R14 PDF

Uploaded by

Copyright:

Available Formats

Arrangement Architecture - Core - T3AAC - R14 1

The AA module provides a flexible framework that allows a number of products

It is possible to have variations in a single product based on channel, customer

Arrangement Architecture - Core - T3AAC - R14 2

Arrangement Architecture - Core - T3AAC - R14 3

Arrangement Architecture - Core - T3AAC - R14 4

Arrangement Architecture - Core - T3AAC - R14 5

Arrangement Architecture - Core - T3AAC - R14 6

Arrangement Architecture - Core - T3AAC - R14 7

Arrangement Architecture - Core - T3AAC - R14 8

Arrangement Architecture - Core - T3AAC - R14 10

Arrangement Architecture - Core - T3AAC - R14 11

Arrangement Architecture - Core - T3AAC - R14 12

Arrangement Architecture - Core - T3AAC - R14 14

Create an arrangement for Current Account product under Current Account

Arrangement Architecture - Core - T3AAC - R14 15

Use the menu path displayed to create a current account arrangement.

Arrangement Architecture - Core - T3AAC - R14 16

Arrangement Architecture - Core - T3AAC - R14 17

Arrangement Architecture - Core - T3AAC - R14 18

The arrangement is now authorised.

Arrangement Architecture - Core - T3AAC - R14 19

Arrangement Architecture - Core - T3AAC - R14 20

Thus a Component has common Attributes and Actions across different

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

Arrangement Architecture - Core - T3AAC - R14 22

Arrangement Architecture - Core - T3AAC - R14 23

In this case PRINCIPALINT and PENALTYINT are instances of the Interest

Arrangement Architecture - Core - T3AAC - R14 24

Arrangement Architecture - Core - T3AAC - R14 25

A Product Group is made up of a sub-set of the Property Classes of its Product

Arrangement Architecture - Core - T3AAC - R14 27

Further we have two Properties - Principal Interest and Penalty Interest as

Arrangement Architecture - Core - T3AAC - R14 28

Arrangement Architecture - Core - T3AAC - R14 29

Arrangement Architecture - Core - T3AAC - R14 30

Arrangement Architecture - Core - T3AAC - R14 31

To summarise, PROPERTY.CLASS definitions are released by Temenos

A Property is a named instance of a Property Class. Properties can be created as

Arrangement Architecture - Core - T3AAC - R14 32

Arrangement Architecture - Core - T3AAC - R14 33

Arrangement Architecture - Core - T3AAC - R14 34

Arrangement Architecture - Core - T3AAC - R14 36

Arrangement Architecture - Core - T3AAC - R14 37

One of the Product Conditions (25 yr Mortgage) of TERM.AMOUNT Property

Arrangement Architecture - Core - T3AAC - R14 38

Arrangement Architecture - Core - T3AAC - R14 39

Arrangement Architecture - Core - T3AAC - R14 40

Arrangement Architecture - Core - T3AAC - R14 41

Arrangement Architecture - Core - T3AAC - R14 42

Arrangement Architecture - Core - T3AAC - R14 43

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

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

Arrangement Architecture - Core - T3AAC - R14 45

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

Arrangement Architecture - Core - T3AAC - R14 46

Arrangement Architecture - Core - T3AAC - R14 47

Arrangement Architecture - Core - T3AAC - R14 49

Arrangement Architecture - Core - T3AAC - R14 50