T24 Arrangement Architecture Product Summary

Temenos T24
Arrangement Architecture (AA)
Product Summary

TEMENOS Confidential
Information in this document is subject to change without notice.
T24 Arrangement Architecture Product Summary

1.0 15/08/06 S. Makrinos Initial document release.

1.0 26/09/06 S. Makrinos Clarification and corrections.
1.0 07/11/06 S. Makrinos Fragmented Activities section.
1.0 09/01/07 S. Makrinos Renamed
1.0 14/09/07 S. Makrinos Renamed Defined Properties to Product
Conditions
1.0 03/06/08 Malcolm Renamed Transaction Rules to Activity
McDonald Restriction; Negotiation Limits to Negotiation
Rules; Renamed Defined Properties to Product
Conditions

TEMENOS Confidential
T24 Arrangement Architecture Product Summary

TEMENOS Confidential
T24 Arrangement Architecture Product Summary

Table of Contents
Summary.......................................................................................................................................1
Product Builder and Catalogue..................................................................................................2
Overview.........................................................................................................................................2
Product Lifecycle............................................................................................................................3
Product Definition Structure.........................................................................................................3
Property Classes and Product Lines (Temenos Defined).............3Properties and Product
Groups........................................................................................................................................4
Product Conditions...................................................................................................................5
Products......................................................................................................................................6
Product Inheritance (Families)......................................................................................................8
Product Catalogue..........................................................................................................................9
Publishing Products..................................................................................................................9
Selecting a Product..................................................................................................................10
Arrangements.............................................................................................................................10
Opening an Arrangement............................................................................................................10
Relationship between Products and Arrangements.................................................................10
Changing Product.........................................................................................................................10
Closing an Arrangement..............................................................................................................11
Activity Based Processing.........................................................................................................11
Overview.......................................................................................................................................11
Activities, Actions, and Accounting......................................................................................11
Activity Logging, Backdating, and Reversals......................................................................11
Future Directions.......................................................................................................................12
Modelling and Simulations.........................................................................................................12
Bundled Products.........................................................................................................................12
Relationship Pricing.....................................................................................................................13

TEMENOS Confidential
T24 Arrangement Architecture Product Summary

Summary
Temenos is developing the T24 Arrangement Architecture (AA) to provide a comprehensive,
component based product definition and servicing framework.

TEMENOS Confidential Page 1

T24 Arrangement Architecture Product Summary

PRODUCT BUILDER AND CATALOGUE

OVERVIEW
The Product Builder is constructed on the premise that all products are constituted from a
number of fundamental business components (Property Classes). Each of these Property
Classes consists of a number of conditions (e.g. interest rate, day basis, margin, etc.) which
control the characteristics of a Product, and a number of actions, which control its processing.
For example, loan interest, deposit interest, penalty interest and commission all share the
same basic conditions and actions and these should therefore all be described via a generic
“Interest” Property Class. Within this “Interest” class, users have the ability to describe all of
the characteristics and processing required to support any interest based characteristics of
any product.
The advantage of this approach is that the Arrangement Architecture provides consistency
and high levels of functionality across all products (e.g. if a loan can have tiered interest, then
by default a credit card or savings account can also have tiered interest). Similarly, when we
enhance our software to support a new Property Class feature, this capability becomes
available across the whole system not just within a specific product line.
There are a finite number of Property Classes (e.g. Interest, Term Amount, Charge, Payment
Schedule, Activity Restriction, etc.) which Temenos defines and combines to describe high-
level product classifications or Product Lines (e.g. Lending, Deposits, Accounts, Credit
Cards, etc.). It is these Product Lines, which are the basis for the creation of the products,
which will be sold and serviced.
The Product Builder is hierarchical and allows the derivation of product structures from
higher levels. For example, a Product (e.g. 15 year Fixed Rate Mortgage) will be derived
from a Product Group (e.g. Mortgages), which will be derived from a Product Line (e.g.
Lending).

Figure 1 - T24 Product Builder Hierarchy

In addition to this structural hierarchy, the Product Builder enables the definition of
“families” of products through Product Inheritance. This allows for a derivative of a product

TEMENOS Confidential Page 2

T24 Arrangement Architecture Product Summary

to be defined by simply specifying a “parent” product and any different conditions. This
approach offers rapid time-to-market for new products and simplified maintenance of
related products.

Product Lifecycle
A financial institution controls the lifecycle of its products through the Product Builder.
There are essentially four main states for a Product. Designing, Proofing, Published, and
Expired. They are shown below in the Product Lifecycle state diagram:

Since products can change over time, each Product record is effective-dated. This indicates to
the system when the Product with the conditions specified becomes effective (i.e. for sales
and for processing). The effective date also indicates the version of the product. A user may
look at historical versions of a product and view the difference between product versions.

Product Definition Structure

Property Classes and Product Lines (Temenos Defined)

A Product Line is described by the Property Classes which constitute it and those which do
not.
The “Lending” line and “Account” line will have a number of common classes such as
“Interest” and “Charge” and at least one distinguishing class, which in the case of “Lending”
could be an “Overdue” or “Credit Limit” class.
Product Line Product Line
Lending Account

comprised of comprised of

Payment
Interest Charge Interest Charge
Schedule

Activity
Overdue Limit Balance Rules
Restriction
Property Classes Property Classes

Figure 2 - Example Lending vs. Account Product Lines

The Property Classes and Product Lines which are available are defined by Temenos (i.e. this
is the code). The financial institution uses these “building blocks” of functionality to
construct the individual products which are available for sale to its customers.

TEMENOS Confidential Page 3

T24 Arrangement Architecture Product Summary

Properties and Product Groups

While the Property Classes define the fundamental building blocks, a more specific
classification is necessary to fully describe a product. For example a loan product may
require more than one type of “Interest” (i.e. “normal interest” and “penalty interest”). To
satisfy this requirement the Product Builder has a concept of a Property which is a named
type of Property Class.
Example Properties of the “Interest” class would be “principal interest”, “penalty interest”,
“credit interest”, “debit interest”, etc. Each of these Properties would share a common set of
characteristics and processing. It is in fact these lower level Properties to which defined
conditions (i.e. specific interest rates) are attached in order to create the products that are
available for sale.

Figure 3 - Example Interest Properties

While the Property Classes are defined and released by Temenos, the underlying Properties
are created and maintained by users. Any number of Properties can be defined providing an
extremely powerful and flexible means of creating new innovative products. For example if
a product type was desired that required three separate interest rates with different
calculation methods the user would simply create (or reuse) the three Properties of an
“Interest” Property Class.
Once the necessary Properties have been created, the designer can use them to define a
Product Group by specifying the mandatory and optional Properties which comprise it.

Figure 4 - Example Personal Loans Product Group

The purpose of a Product Group is to provide a structure and constraints to any products
derived from the group.

TEMENOS Confidential Page 4

T24 Arrangement Architecture Product Summary

Product Conditions
Each saleable Product is comprised of specific Product Conditions (i.e. real values assigned to
each of the Properties) which specify any default values, negotiation rules, and periodic
rules.

“Library” of Product Conditions

Product Conditions are not specific to a single Property (e.g. Principal Interest or Penalty
Interest) and can therefore be reused extensively. This results in the creation of a Product
Condition “Library” from which specific Products can be built.
Term Amount Interest Charge

15 Year Standard 5% Flat Rate LIBOR + 0.5% $500 Flat % Banded

30 Year “Jumbo” FedFunds – 0.75% Treasury $5 per Unit 0.25%

Payment Schedule Overdue Settlement Activity Restriction

No Early
Annuity No Grace Direct Debit Full Disbursement
Repayment
$5000 Maximum
Fixed Principal 10 Days Grace Billed $50,000 Multiples
per Transaction

Figure 5 – Example "Library" of Product Conditions

Defaults and Negotiation Rules

Some conditions within each Product Condition will have default values (i.e. interest rates)
and/or ”negotiation rules” to ensure that the any condition value entered in an Arrangement
is within the constraints which have been defined. This allows for users to negotiate specific
arrangement characteristics within pre-defined limits. Where negotiation is not allowed, the
negotiation rules can be removed and the default value will become fixed.

Periodic Rules
Several Property Classes allow for the specification of Periodic Rules, allowing the product
designers to specify restrictions on product conditions for certain periods of time (e.g.
monthly, yearly, arrangement lifetime, etc.)
As an example, a product may be specified as having an initial interest rate of 5% which can
increase no more that 1% during each 12 month period and a total of 3% during the term of
the arrangement. Similarly Periodic Rules can be used to specify transaction restrictions such
as the number and value of withdrawals or disbursements allowed within a specified period
or periods.

TEMENOS Confidential Page 5

T24 Arrangement Architecture Product Summary

Products
A Product (e.g. Car Loan) is derived from a Product Group (e.g. Personal Loans), and made
available for sale to customers.

Figure 6 - Example of Products in the Personal Loans group

Assigning Product Conditions

To create a Product users link the desired Product Conditions (e.g. 5% flat rate) to the
appropriate Properties (e.g. Principal Interest).
Term Amount Product Payment Schedule

15 Year Standard 15 Year Mortgage Annuity

30 Year “Jumbo” Principal Fixed Principal

Principal Interest
Interest Overdue

5% Flat Rate Penalty Interest No Grace

FedFunds – 0.75% Repayment 10 Days Grace

LIBOR + 0.5% Overdue

Activity Restriction

Disbursement Full Disbursement

Charge

$500 Flat Early Repayment $50,000 Multiples

% Banded Administrative Fee No Early

Repayment

Figure 7 - Example of Linking Product Conditions to form a Product

Although many Products will have only a single set of conditions attached to each Property,
the Product Builder enables a user to link multiple Product Conditions to each Product
Property through user defined rules. Users will define these rules through the T24 Rules
Engine and can then use these rules to specify which Product Conditions should be applied.
As an example, this will allow for a single Product to be defined which may have preferential
conditions based upon characteristics of the customer or their relationship with the bank.
The selection of Product Conditions is done dynamically during the creation and during
processing of each Arrangement.

TEMENOS Confidential Page 6

T24 Arrangement Architecture Product Summary

Product Availability
The financial institution makes Products conditionally available by specifying allowed
currencies and through user-defined rules. Users can create segmentation rules (e.g.
Platinum Customer, Standard Customer, Internet Only, etc) and make products available
only when these rules are met.

Changing Product Conditions

As economic conditions change over time, the characteristics of products are likely to change.
These changes will be entered as updated Product Condition records with new effective
dates. This method allows a change to be scheduled for a future date. Additionally, back-
dated changes can also be entered in the same fashion. A full history of all Product
Conditions, which were applicable to a Product at any point in time, is available.
In addition to dated changes of a single Product Condition, the Product Builder also allows a
Product to be defined with “timed” changes of its conditions. These timed changes are
handled as either “product changes” (i.e. an introductory product is set for a given period
after which the arrangement will revert to a standard product) or as “condition changes” (i.e.
a standard product property is linked to one Product Condition and after a period of time
switches to a different Product Condition.
The difference between the two types described above is that in the case of the product
change, there are two defined products both of which exist independently. In the second
example there is only one product whose conditions change after a given period.

TEMENOS Confidential Page 7

T24 Arrangement Architecture Product Summary

Product Inheritance (Families)

A key feature of the Product Builder is Product inheritance. This allows for the creation of
product families where derivatives of a generic product or sub-product can be quickly
created by simply defining the delta (in terms of product conditions) between the new and
existing product. This means that where a Product Condition is not specifically defined it
will be inherited from the parent product, grandparent product, etc.
For example a bank may wish to offer a range of car loans with rates varying based on the
type of car and the term of the loan. A generic “car loan” product would be defined where
all the standard terms and conditions such as base interest rate, max and min principal
amounts, early redemption penalties and charges can be defined. The actual products to be
sold can then be defined as derivatives of this base product where only the interest rate, term,
and overdue processing change. For each derivative product it would only be necessary to
specify the relevant Product Conditions that differ from the parent product.
CAR LOAN

Property Product Condition

PRINCIPAL PRIN.CL1 At the “Product” level we can
define generic Product
TERM TERM.CL1 Properties for the Properties
PRINCIPAL INTEREST PRIN.INT.CL1
that are mandatory for the
Product Group.
REPAYMENT REPAY.CL1

OVERDUE OD.CL1

At the “Sub-Product” level

NEW CAR LOAN USED CAR LOAN
only those properties that
Property Product Condition Property Product Condition differ from the parent need
PRINCIPAL PRIN.UCL1 to be defined. All other
properties will be inherited
from the parent.
PRINCIPAL INTEREST PRIN.INT.NCL1 PRINCIPAL INTEREST PRIN.INT.UCL1
Additional optional
properties can also be
OVERDUE OD.NCL1 added at the sub product
level.
PENALTY INTEREST PEN.INT.NCL1 PENALTY INTEREST PEN.INT.UCL1

USED CAR LOAN – 5 YEARS USED CAR LOAN – 3 YEARS

The same Property Product Condition Property
Product
Condition
inheritance
principal applies
at all levels in a TERM TERM.UCL5 TERM TERM.UCL3

product hierarchy PRINCIPAL INTEREST PRIN.INT.UCL5 PRINCIPAL INTEREST PRIN.INT.UCL3

with an unlimited
number of levels.

Figure 8 - Product Inheritance

When defining these “child” products, the user will specify the “parent” product and all the
characteristics of the parent will be displayed. Any Product Conditions which are changed
will be stored for the “child” product and all others will be treated as inherited. Whenever a
parent product changes the affected derived products will be rebuilt.

TEMENOS Confidential Page 8

T24 Arrangement Architecture Product Summary

Product Catalogue

Publishing Products
Once a Product has been defined through the Product Builder it must be published to be
made available for sale. To publish a Product, T24 will effectively work its way down the
Product hierarchy populating all the conditions on each characteristic according to the
principal of inheritance described above. These characteristics will then be recorded in the
published catalogue. If a change is then made to a higher-level product it will not be
reflected in any derived products until the product catalogue is republished. This process is
shown in the diagram below.
PRODUCT BUILDER PUBLISHED PRODUCT CATALOGUE
CAR LOAN
Property Product Condition
PRINCIPAL PRIN.CL1

TERM TERM.CL1

PRINCIPAL INTEREST PRIN.INT.CL1

REPAYMENT REPAY.CL1

OVERDUE OD.CL1

NEW CAR LOAN USED CAR LOAN

Property Product Condition Property Product Condition When a Product is
PRINCIPAL PRIN.UCL1 published all of the
Product Conditions
are assembled
PRINCIPAL INTEREST PRIN.INT.NCL1 PRINCIPAL INTEREST PRIN.INT.UCL1
from the various
levels in the
OVERDUE OD.NCL1
hierarchy into a
single product
PENALTY INTEREST PEN.INT.NCL1 PENALTY INTEREST PEN.INT.UCL1
definition record

USED CAR LOAN – 5 YEARS USED CAR LOAN – 3 YEARS USED CAR LOAN – 3 YEARS

Property Product Condition Property Product Condition Property Product Condition

PRINCIPAL PRIN.UCL1

TERM TERM.UCL5 TERM TERM.UCL3 TERM TERM.UCL3

PRINCIPAL INTEREST PRIN.INT.UCL5 PRINCIPAL INTEREST PRIN.INT.UCL3 PUBLISH PRINCIPAL INTEREST PRIN.INT.UCL3

REPAYMENT REPAY.CL1

OVERDUE OD.CL1

PENALTY INTEREST PEN.INT.UCL1

Figure 9 - Product Publishing

This will effectively allow the users to build and modify products without affecting the
current banking operations. In fact the product building process will need to be a three-stage
operation consisting of design, proof, and publish stages. The products to be published will
first be built in a proofing area (the hierarchies and inheritance applied) so that fully
populated product conditions are available for each product for review without impacting
the current set of live products. Once reviewed, any further modifications made, and re-
proofed the new products can be published. This will generate a new effective dated product
record in the published product catalogue.

TEMENOS Confidential Page 9

T24 Arrangement Architecture Product Summary

Selecting a Product
A T24 user can choose an AA product directly through the Product Catalogue by searching
by product characteristics. Clients using Temenos ARC® can use the details of the Product
Catalogue for cross-selling and marketing campaigns.

Arrangements

Opening an Arrangement
Once a Product has been published to the Product Catalogue it becomes available for sale.
To create a new arrangement (i.e. a loan) a user will select a product from the catalogue and
T24 will default all of the conditions defined for the product. The user will then input any
necessary conditions (e.g. amount, term, dates, etc.), which have not been defaulted from the
product. Both defaulted and user input conditions must be within the negotiation rules
specified in the product definition (e.g. amount between 10,000 and 100,000).

Relationship between Products and Arrangements

The Product Builder will support a number of options in terms of how each arrangement will
be affected by changes to its Product definition.
To provide the highest level of flexibility, each set of Product Conditions on a Product will be
defined as non-tracking, tracking, or custom tracking.
Non-tracking – Once the arrangement has been opened, all conditions for a specific Property
will be set for the duration of the arrangement. Subsequent changes to the “non-tracking”
product conditions will not affect the arrangement.
Tracking – The Product Conditions of a Property will contain values for all mandatory
parameters. At the arrangement level the user cannot change any of the conditions of the
Property. Throughout the duration of an arrangement any product level changes to a
“tracking” property will be reflected in the arrangement.
Custom Tracking – This type of arrangement property behaves in a similar way to
“tracking” properties except that individual conditions can be input (subject to negotiation
rules) at the arrangement level. Any attributes, which have been input, will effectively
become fixed for the duration of the arrangement. All other attributes will track changes at
the product property.

Changing Product
During the lifetime of an Arrangement, T24 allows the Product of an Arrangement to be
changed to another Product within the same Product Group 1. This change can be manual or
pre-defined in the product (e.g. an “introductory” product which after a period of time
reverts to the conditions of the “standard” product).

1
Future enhancements may provide for additional Product changing flexibility.

TEMENOS Confidential Page 10

T24 Arrangement Architecture Product Summary

Closing an Arrangement
Arrangements in T24 will be closed/matured through a “Close Arrangement” activity. This
activity can either be initiated manually by the user (e.g. the customer would like to close
their current account) or automatically by T24 (e.g. deposit maturity).

Activity Based Processing

Overview
Servicing of T24 Arrangements is accomplished through Arrangement Activities. Activities
are business functions which are triggered either by a user, the close of business, or another
T24 application like Funds Transfer or Teller.
Examples of Arrangement Activities are:
 New Arrangement
 Change Interest
 Recalculate Payment Schedule
 Process Payment
 Close Arrangement
Unlike most other T24 applications in which the user enters data in a record and T24
determines the required actions, an Arrangement Activity is first explicitly selected and any
necessary input is restricted to the appropriate attributes.

Activities, Actions, and Accounting

Each Activity is comprised of one or more Actions which are the specific units of processing
performed by a Property Class (e.g. Send Bill or Calculate Interest). Actions can only be run
via an Activity and therefore servicing of an arrangement is exactly the same whether
running online or during the close of business (i.e. single source).
Additionally, certain Actions may require accounting. During product definition, event-
based Accounting Rules are established and linked to the relevant Actions.

Activity Logging, Backdating, and Reversals

Each Activity performed on an arrangement is effective dated and stored on the
arrangement’s Activity Log. T24 stores the sequence of activities, links to any financial
transactions (e.g. deposits, withdrawals, disbursements, repayments, etc.), and links to all
accounting entries.
The combination of an effective dated Activity Log and single-source processing allows for
the servicing of activity reversals as well as backdated activities.

TEMENOS Confidential Page 11

T24 Arrangement Architecture Product Summary

Upon reversal of an activity, T24 effectively reverses any subsequent activities and then
replays the arrangement moving forwards as if the reversed activity had not occurred. This
can result in new activities (e.g. overdue processing) occurring as a result of the reversal.
To process a backdated activity, T24 follows the same procedure used for reversed activities
(i.e. reversal and replaying of subsequent activities.

Future Directions

Modelling and Simulations

The T24 Arrangement Architecture is based on Activity processing. In order to provide
modelling of both Products and Arrangements a future enhancement will allow for
simulation of new products, changes to existing products, and changes to arrangements by
effectively “playing” the activities that should occur over the specified time period. In
addition, users will be able to specify future/back dated activities which will be considered
during the simulation.
Since the modelling/simulation process will “play” the same activities as the production
products, the simulation results will be as accurate as is possible.

Bundled Products
The T24 Arrangement Architecture will be the basis for product bundling. Product bundles
are often created in order to encourage customers to establish more arrangements with the
financial institution by offering preferential conditions (e.g. better interest rates,
lower/waived fees, etc.).
A typical example may be an offset mortgage where the credit balance of a customer’s
current account may be used to offset the principal outstanding of the loan:

Figure 10 - Example of a Bundled Product

Additionally very complex products can often be created by combining multiple simpler
products.
The following is a high-level description of the functionality, which will be supported. This
functionality should not be considered comprehensive as market forces and client
requirements may result in Temenos adding additional features or changing developments
schedules and priorities.
 A Product Bundle is defined through the Product Builder and is comprised of a
user-defined number of Constituent Products.

TEMENOS Confidential Page 12

T24 Arrangement Architecture Product Summary

 The financial institution may decide to sell Constituent Products individually or

only as part of a Product Bundle.
 Constituent product arrangements may be owned by different customers
although they must all be customers of the Arrangement Bundle.
 When defining a Product Bundle, users may specify:
o the Constituent Products and whether each product is mandatory or optional
o whether multiple arrangements of a Constituent Product may be included in
the Arrangement Bundle (e.g. one mortgage bundled with one or more
savings accounts).
o the method by which the Arrangement Bundle is created/managed (e.g. all
products purchased and established at once, products added to a bundle over
time, etc.)
o the Product Conditions specified in the Product Bundle:
 Overriding Conditions which alter specific constituent product
conditions (e.g. the interest conditions on an offset mortgage).
 Bundle Conditions which are in addition to any constituent product
conditions (e.g. an administrative charge for establishing up the
bundle or an annual “bundle statement” charge).
Product Bundling will be released as a T24 AA Product Line and may include additional
Property Classes necessary for the definition of a bundle.

Relationship Pricing
Temenos is currently gathering requirements for Relationship Pricing. At a minimum, a
mechanism will be created through which financial institutions can specify preferential
pricing conditions (i.e. charges and interest) at the customer or customer group (i.e. related
customers) level based upon the complete financial relationship with the institution.
While this area has yet to be fully defined, we expect that many of the concepts and methods
related to Product Bundling will be reused and expanded.

TEMENOS Confidential Page 13