T3TAAC Arrangement Architecture Core R15 v3.1

T24 Arrangement Architecture - Core T3AAC - R15

1

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

T24 Arrangement Architecture - Core - T3AAC R15

2



3



4

Almost all banking solutions including traditional T24, contain product silos. The related functionality and product features exist within the respective silos. In this instance, reusability is limited, creation of a new product / innovation / modification in an existing product is difficult. Innovation is about the Financial Institution’s ability to innovate new products to offer their customers and thus maintain their competitive edge in the market. We, as their partners, should have the ability to support such innovation with product features and flexibility.

5

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.

6

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


7

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

8

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


9

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

T24 Arrangement Architecture - Core -T3AAC R15

10


11

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.


12

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


13

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.


14


15

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


16

Create an arrangement under Current Account Group and select the Current Account product. Commit the Arrangement and get it authorised.


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


Input customer ID and currency of arrangement and validate the record. We may notice that on creation of the new Arrangement we had AAACT…. Which is the activity ID of creation of this arrangement. We would discuss about Activity in detail during this course. On validating the record the AA version would come up and the arrangement id is generated. We can see the components of the arrangement in this version. We would read how to default values to these components, whether they can be amended and if so, on what limitation in the duration of this course. You may note that under the Account tab highlighted the Account number associated with this arrangement is can be seen. Now, commit the record.


In order to authorise the record, open the record in unauth status.


The arrangement is now authorised.


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



23

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.


24

The Components for vehicles vis-à-vis Banking products are compared.

In our example, the Wheel Component of Similar vehiclestoare compared with the Interest Component of Banking Products. other Components of Vehicles viz. Transmission, Engine, Body, etc. we can think about the Components Payment schedule, Charges, Term Amount (Period plus Principal) of Banking Products. In AA, the Attributes and Actions of Components are defined for every Property Class.


25

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


26

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


27

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


28

In AA under each Product Line, multiple Product Groups can be created by Clients. While the Product Line has been defined by Temenos which is a combination of Property Classes, Clients can create their own Product Groups under a Product Line. A Product Group is a sub-set of the Property Classes of its Product Line. Of course, all the mandatory Property Classes need to be retained in a Product Group and optional Property Classes may be included or omitted. Further, at a Product Group level, we actually need to specify the Properties (atleast one) for each Property Cl ass.


29

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


30

In AA under each Product Group, multiple Products can be created by Clients. It is finally the Products which a Bank can offer to its Customers. And it is THAT specific product, for that customer, which is the contract called an Arrangement.


31

A Product Condition is a set of rules set for a Property Class . It defines the default values for its Attributes. It is also used to define certain other conditions like Negotiation Rules, etc. which we will discuss later. Example: For Interest

Property Class, we can define a Product Condition with the Interest Type Attribute set to Fixed, Rate set to 5, and set other rules.


32

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.


33

Answers: 1. a 2. b 3. a


34

4. a 5. b 6. a


35


36

To summarise the features of Product hierarchy: It is possible for a Product to have only one Parent Product, while a Parent Product may have multiple Child Products. A Parent Product and child products down the line must be of the same Product Group. A Product can be set to either “saleable” or it could be only for inheritance. What this means? When a Product is saleable, it means it is complete with Product Conditions for all its Properties. When it is only for inheritance, it means the Product is not complete i.e. All the Properties of the Product are not defined with Product Conditions . In this case, its only use will be to be a Parent such that Products at a lower level will inherit its Properties.

It is possible to set a Parent Product also as saleable. This just means that in addition to being saleable, its Properties can be inherited by its Child Products. The benefits of Product Inheritance are : 

Clear organization of Product hierarchy



Each saleable Product can be much simpler



Differences between Products are immediately apparent



Variations of Products can be easily done


37

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


38

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


39

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


40

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


41

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


42

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


43

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


44

Properties.


44

Now that you have an understanding of how a Product is designed, we will see what an Arrangement is. An arrangement is an instance of a Product associated with a Customer. In simple words, for a financial Product, when a Product is sold to a Customer, it becomes an Arrangement with the Customer. Creating an Arrangement involves “negotiating” with the Customer for changes to the standard product specification. Technically an Arrangement is created with a copy of the Product Conditions, some of which can then be modified, and some cannot. You will learn about what is negotiation in the next page. With the car analogy, the engine cannot be modified, the wheels can optionally be modified, and the colour must be chosen. This means that while the engine cannot be negotiated, the wheels and colour can be negotiated.


45

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


46

1. a 2. b 3. c


47


48

Product Builder of AA can be used to construct AA Products and publish it 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), Relationship Pricing (for Preferential Pricing), Product Bundle, Mobile Services, Proxy Services and Agent . Product Lines can be crea ted only by Temenos and they cannot be created by the User. These “building blocks” can be used to go to the next level of Product Groups, which are pre-defined for select T24 applications . They are user definable for other products. The final stage is defining the Products which are completely user definable. These individual Products are made available for sale to Customers by including them in Catalog.


49

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


50

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, Agent 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 which are built through AA.PRODUCT.GROUP. These can be built by Clients. The property classes also have been pre defined for each of the Product Lines. Thus, they get the basic attributes of the product line. Property classes are pre defined by Temenos. The classes are like Interest, General Charge etc. However every property class may have one or more distinct properties. These are user definable . Under interest, user can define a fixed interest or floating interest with or without margin as different properties and pick what is needed for a particular product.


51

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


52


53

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


54

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.


55

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.


56

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.


57


58

You have learnt earlier that a Property Class is a fundamental building block of AA and that a Product Line is a combination of Property Classes. Property Classes are released by Temenos and you can only amend their Description. The components are reusable and can be used across several Products.


59

Property Classes are building blocks, released by Temenos and you can only amend their Description. Financial institution uses these functionality of “building blocks” to construct individual products which are available for sale to its customers. (Navigate: admin/product builder/properties => select a CLASS ) 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.


60

MERGE – Allows Child condition not to override parent condition blindly. 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.


60

Product Commission property class enables configuration of financial product line / product Group / Products those are eligible for Rewards calculation. Can define if rewards are paid immediately or is scheduled. This property class is applicable for Agents and Rewards product line . Agent Commission Property Class links the Rewards arrangement/Agent Arrangement to the Financial arrangement. Provides the ability to override the predefined Rewards/Commission that is defaulted from Product commission.


61

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 w ith any of the previously amended arrangement values. Currently, only BALANCE.MAINTENANCE is defined with this type. TRIGGER – Properties related. When to thiscertain property class will not appear Arrangement Activity s creen activities related to thesein 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


62

triggered and validated.


62

VARIATION: From R14 Variation is a Type which can have an additional component in the Product condition. Variations enables 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 IDs of the product conditions .

A virtual table AA.PRODUCT.VARIATION holds the list of available product variations. 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 rd conditions for products subscribed through “Internet”. The 3 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.


63

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


64

AA.PROPERTY.CLASS.ACTION is the application which holds information on actions which can be performed with a PROPERTY CLASS The user will be able to get information on whether the action will generate an accounting entry and also which Product Line will be affected. (Navigate: Admin/Product Builder/ Additional Settings/Actions => Select Interest > Accrue Action )


65

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


66

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


67

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


68

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 and past 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 define the AA.PROPERTY.CLASS records type as variation another step to configure is to flag the AA.PROPERTY record also

to be a variation. propertyspecific of Property thatproperty is variation specific can have a property can beA variation whileClass another of same property class need not have any variations. Remember if variation condition defined for a property, at Proofing and Publishing stage if a Property isn’t flagged as a variation, an error will be shown


69

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


70

From R15, we have two new property types Rebate Unamortised –

There canthem be any number of charge associated with a loan Amongst only few might haveproperties a requirement to rebate back the product. proportional amount. Rebate unamortized property type identifies the properties for which rebate functionality is required. Properties which are marked with this property type would only be rebated back. Normal charges without property type as Rebate Unamortised can be set to amortize. When an arrangement with such a charge definition is paid off, it should recognise the unamortised amount immediately, without depending on the configuration in payment schedule. Periodic. Charges cannot be of the type Rebate unamortized. Property type “COMMISSION” is introduced to identify charges those are used as commissions. The bills that are generated for these charges indicate that they are commissions. Null indicates that it is a normal property, there are no special features


71

Create new property for Customer Property Class


72

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


73


74

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


75

What is the underlying application that is used to store all the information about Product conditions? Do you still remember? Product Conditions belong to a Property Class and you can create different Product Conditions for a Property Class For each Product Condition you can create different dated records For each Property class a separate application is created with the name AA.PRD.DES.. You will see an example for this in the next page.


76

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


77

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.


78

Each Product Condition record in T24 has an Effective Date. The effective date represents the date on which that particular set of values takes effect for a Product and for any Arrangements which “track” Changes to Product Conditions

are typically controlled by effective dating. Note that any Product Condition can be set for Tracking at a Product level. This allows you to set up any changes to Product Conditions in advance, and when Product using the conditions has been re-published, they will automatically switch over to the new condition on the effective date. When you do not specify a date in the Id of a Product Condition, date part of the Id defaults to the today’s system date.


79

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.


80

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 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 is: VEHICLE.LOAN-BRANCH-20100101 If the AA.PROPERTY.CLASS type is defined as “Variation” then the ID structure of the product condition would have one additional component, which could accept any value defined in the virtual table.

When a key is defined in AA.PRD.DES.XXX of a property class which supports variation, a validation would be done to check whether it is a valid variation defined in AA.PRODUCT.VARIATION virtual table and error message is displayed if the same is not found


81


82

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


83

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


84

Negotiation Rules are used to specify which attributes may be amended at the Arrangement level, and which must remain the same across all Arrangements. For each attribute that is modifiable, the negotiation rule defines the rules by which they may be modified. For example, a product may be specified as having a base term of 5 years. At the arrangement level, the bank may wish that the user have the ability to negotiate from 3 to 10 years, A user would define a negotiation rule on the TERM.AMOUNT property condition for the TERM attribute with a “MINPERIOD” of 3Y and a “MAXPERIOD” of 10Y.

Another typical example would be the amount of a loan. Most loan products do not have a default value but rather have a minimum and maximum amount. This is accomplished by the definition of two negotiation rules on the Term Amount property for the AMOUNT attribute.


85

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


86

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


87

Let us learn about the multi-valued NR.ATTRIBUTE field. This specifies the attribute of the Property Class, for which a negotiation rule is to be defined in the associated fields NR.NEGOTIABLE through to NR.MESSAGE. These attributes will become the fields in the Arrangement. Must be a valid attribute of the Property Class. In this example, where the Product Condition is set for the TERM.AMOUNT Property Class, it should be a valid attribute name of the TERM.AMOUNT Property Class.


88

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 We will explain about these values in the next page.


89

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.


90

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.


91

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.


92

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.


93

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 you are changing to. 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


94

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


95

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


96

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


97

A new Term amount product condition with ID as TERMAMOUNT 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.


98

1. b 2. c 3. b


99

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 Perio dic 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


100


101

We can see the Periodic Attribute Class defined for every Property Class

For each Periodic Attribute Class we have some predefined Periodic Attribute.


102

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


103

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.


104


105

You have learnt earlier that a Property Class is a fundamental building block of AA and that a Product Line is a combination of Property Classes. Property Classes are released by Temenos and you can only amend their Description. The screen here shows the Product Hierarchy in AA and what they are about at each level.


106

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


107

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


108

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


108

Single:

Remember in order to give a 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 taking NEW arrangement to throw error when multiple arrangements are taken under a si ngle product. Property Classes that constitute the line are to be 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


109

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


110

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


111

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.


112

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.


113

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


114

We will discuss about AA Activities later in the course.


114

Create a new Product Group with the Property classes and properties as given above. Hint: Do not leave any line w ithout a property. Go sequentially down and remove(with ‘-’ ) any unwanted classes for this group


115

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.


116

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 Productcannot 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 theirdown own. the They are onlytoabstract definition product which should be derived hierarchy define the productofina its entirety.


117

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.


118

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


119

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 s et to Fix-Value in Product Condition, it will not track changes to Product Condition. All other Attributes will track changes to Product Conditions.


120

There is a relation between the TYPE field of a Property Class and how the ARR.LINK Field can be set for its Product Condition in a Product: If TYPE is set to TRACKING ARR.LINK can be set to TRACKING or CUSTOM.TRACKING or NON.TRACKING. It indicates that the given property can be set to tracking. If TYPE is set to NON.TRACKING ARR.LINK can only be set to NON.TRACKING If TYPE is set to TRACKING.ONLY ARR.LINK can be set only to TRACKING


121

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


122

AA allows the flexibility to attach multiple conditions for the same property. The subsequent conditions are effective after a time period, which is also defined at the product level. Effective : In addition to dated changes of Property, the Product designer also allows a Product to be defined with “timed” changes of its conditions. These timed changes may be defined as “condition changes” (i.e. a standard product property is linked to one defined product condition and after a period of time switches to a different defined product condition. It can be a valid period indicator with W- Week, M-Month, Y- Year and D-Days Effective. Base : Defines the effective period of next(new) condition in field EFFECTIVE. The options are Start, Arrangement and Anniversary . The anniversary option is introduced from R15. START: In case disbursement has happens at a different date than new arrangement creation date then all existing START type conditions will be deleted and new conditions created based on disbursement date of the arrangement. ANNIVERSARY : Bank define interest rate change conditions (Forward conditions) based on ANNIVERSARY date which can be changed at any time during the life of the contract. When an Anniversary date is changed, the existing anniversary conditions are deleted and the new anniversary conditions are created based on the base date as new anniversary date. ANNIVERSARY option is applicable for interest and payment schedule properties ARRANGEMENT : If user doesn’t select any one of above options then system will treat those are ARRANGEMENT type conditions. Forward condition effective date is calculated by considering START.DATE of the arrangement. It will not be changed any of the time. Note: Forward dated product conditions for forward dated properties are still applicable.


123

When creating the new arrangement user can define the future dated rate change for an interest property from the arrangement Level. It will be done by using + button. When user press the + button system will open one relative calendar. It has the relative option START, ANNIVERSARY and ARRANGEMENT. Base date changes for ANNIVERSARY condition 1. New arrangement: - During creation of new arrangement if the user has created any anniversary condition then the new arrangement effective date is considered as the base date. 2. Disbursement & Auto Disbursement: - In account property, BASE.DATE.TYPE field is set as START option and then if the disbursement is executed on a different date other than new arrangement creation date, then the ANNIVERSARY date is changed to disbursement date. In this case if user creates any forward dated ANNIVERSARY conditions they are deleted and the new conditions are created by considering base date as the disbursement date. A new activity LENDING-CHANGE.CONDITION-ARRANGEMENT introduced. 3. Update Account: - Anniversary date can be changed by triggering update account activity. In this case, existing anniversary conditions are deleted and the new conditions are created by taking base date as the new anniversary date 4. Change Product: - Whenever the change product activity is triggered either by user or a scheduled activity, the Anniversary date is changed to effective date of change product activity date. In this case, existing anniversary conditions are deleted and the new conditions created by taking base date as new anniversary date. 5. Rollover arrangement: - Anniversary date is changed to the effective date of roll over activity. In this case, existing anniversary conditions are deleted and the new conditions created by taking base date as new anniversary date. 6. Reset arrangement: - Anniversary date is changed to effective date of reset arrangement activity. In this case, existing anniversary conditions are deleted and the new conditions create by taking base date as new anniversary date.


124


125

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: [in Product Design] 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.


126

For a product that should have variations, we must specify which variations are required and whether there is a default 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.


127

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.


128

1. c 2. c 3. b


129

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


130

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


131

The product conditions are assigned for each property. The calculation source is indicated for the interest property.


132

Create another Product under the Product Group created in the earlier workshop. This product is to be defined as a Parent product by marking INHERITANCE.ONLY. At least one product condition is to be attached to each property. Set the calculation source tab as indicated. (HINT: rest of properties will be inherited from Product Group)


133

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


134

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


135

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 opted for in the product group are defaulted while creating the product. Out of 9 properties, only 4 are chosen for the child product, rest were earlier chosen in the parent product. Suitable product conditions are filled in, arrangement link is set for tracking / non-tracking. Under calculation source tab, CURACCOUNT is set as the balance property for calculating Principal Interest on daily debits.


136

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.


137

New Arrangements can be created only for a Product published into Product Catalog.


137

We have seen how Product Designer allows you to create Products with their Properties and Conditions. The next stage is Proofing. At the proofing stage, we need to set the available date of the product. Proofing validates that the Product has been configured correctly. Proofing includes checking whether all mandatory Properties have been given conditions, that there are no conflicts between those conditions, and any other errors that would prevent the Product from being published. Any errors generated have to be fixed and the product has to be proofed again. Then the Product is published, and it enters the Product Catalog. Now the product is available for sale and can be used to create Arrangements. The proofing and publishing process can be done either “Online” or by running a “Service” in the AA.PRODUCT.MANAGER application. If ONLINE is chosen, system would proof the product immediately. If SERVICE is chosen, the main product (from which the publishing is triggered) is written on to a LIST file AA.PUBLISH.SERVICE.LIST for indicating whether it is a PROOF/PUBLISH initiation. A Service would be introduced AA.PUBLISH.SERVICE (from TSA.SERVICE, )– which –would process this list file. The service would publish products hierarchy-wise. This ensures that a child would not accidentally get published before the parent has been processed.


138


138

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


139

Proof the Parent Product used in the previous workshop with available date as today, then publish the same. HINT: Access the Product and use ‘Manage’ button


140

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


141

Answer: 1. c 2. b 3. b


142


143

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/deposit/account 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 islook easier to use the enquiries and composite screens provided rather than try and at files directly.


144

Create an arrangement for Mortgage product and set the following: Create an Arrangement for Mortgage Product Indicate a commitment amount of 100,000 Input a settlement account under Pay In and pay out settlement tab and ensure Active is set to YES Ensure that payment schedule has disbursement property % as 100% Against DISBURSEMENT type bill Commit the Arrangement, accept overrides and get it authorised


145

The arrangement is created using New arrangement Activity. The commitment amount is input as required. The schedule is verified for full disbursement. Commitment amount is input along with Term. Settlement conditions are set as Active Yes and indicating settlement account


146


147

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 via Correspondence tab (earlier named as “Messages”).

DM.APPLICATION.INFO and DOC.GEN.CONDITION holds 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.


148

Create an Arrangement for your Customer for the above Product You can find your customer defaulted as the primary customer. Add another to the same arrangement Set the term as 1Y, the amount as 75,000 Settlement account to be given suitably in Pay In and Pay Out Settlement Tab Commit the Arrangement and get it authorised Now search for your deposit arrangement using the secondary customer you have added in the arrangement


149

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.


150

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.


151

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


152

It can be enabled at New arrangement activity and also using AA.CUSTOMER.ROLE. More information is covered in Advanced courses.


152

AA.ARRANGEMENT.ACTIVITY Application is used to trigger activities for arrangement. Where does the arrangement actually gets stored? We know that the Product Conditions are based on Property Classes. Product Conditions belonging to a particular Property Class are stored in a separate application that corresponds to the respective Property Class. Are the Arrangement conditions/values also grouped based on Property class? Yes! An arrangement gets stored in AA.ARRANGEMENT, whereas the arrangement conditions relating to the various Property Classes are stored in applications that begin with AA.ARR..


153

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. 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. is Arrangement IdProperty-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


154

Property Class.


154

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) Proofing(Example: AA.PRD.PRF.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


155

Under Property Classes, we had earlier learnt that the Balance prefix is hardcoded for each property class. These balance prefix-es denotes the life cycle of an Arrangement by which financial balance would move from one stage to the other. For instance CUR+BALANCE, ACC+PRINICIPALINT When the property is suspended the accruals are posted to the balance types suffixed with a “SP” instead of PL. T24 has no validations on AC.BALANCE.TYPE record id. Do you know why?


156

AC.BALANCE.TYPE records are either contingent, non-contingent. Balance types can also be classified as internal reporting type. Apart from this we have the virtual balances which are sum of AC.BALANCE.TYPES. These are used for calculation of penalty interest and not reported. There are charge off related AC.BALANCE.TYPE generated automatically by T24 AA framework, if charge off component is configured in the lending product. The AC.BALANCE.TYPES would look like CURBALANCECO, CURBALANCECUST. This is an advanced concept and will be dealt in deal during AA Lending courseware. Note: The type of accounting entry (Spec or Stmt entry) is also mentioned in AC.BALANCE.TYPE record.


157

Virtual balances allow banks to define calculated balances (e.g. sum of three actual balances) for simpler use in product definitions and enquiries. Now we know why there are no validations in AC.BALANCE.TYPE record ID.


158

CALC.PROPERTY Field is used to specify properties require calculations. (e.g. PRINCIPALINT and PENALTYINT are properties require calculation of interest). Calculation is based on a BALANCE indicated in SOURCE.BALANCE Field. This should be a valid AC.BALANCE.TYPE Id. SOURCE.TYPE Field indicates whether calculation is based on Maximum, Average or Daily balance. The data for this field should be a valid record in AA.SOURCE.CALC.TYPE. 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. In this example PRINCIPALINT will use CURACCOUNT Balance type for calculation, while PENALTYINT will use TOTALPENALTY Balance type. Here the TOTALPENALTY type balance is a virtual balance and may include, due principal, overdue principal, overdue charges, etc.


159


160


161

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


162

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.


163

Now we have an idea of what Activities are, let us see how they work in AA.

In AA, Activities associated Properties. A crucial point to note is that, few activities likeare ‘Create New’with , ‘View arrangement’, ‘Takeover activity’ acts on the arrangement (not the property). 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.


164

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.


165

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-DISBURSECOMMITMENT i.e. The amount of the loan is disbursed.


166

Similar to the Properties are named types of Property Classes, we have Activities belong to Activity Classes. While Activity Class is related to a Property Class, an Activity is related to a Property. For example, take Activity Class LENDING-DISBURSE-TERM.AMOUNT. The ID is a combination of Product Line –Process-Property Class. The related Activity will have an ID with a combination of Product LineProcess-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 LENDINGDISBURSE-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 LENDINGDISBURSE-TERM.AMOUNT. Here COMMITMENT is a Property belonging to Property Product Class: TERM.AMOUNT and attached to a Product Group under thethe LENDING 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.


167

Normally Activities are generated automatically when you create or modify a Product Group and request the Activities to be rebuilt. This does not create userfriendly 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.


168

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... These action routines are available and can be reused.


169

To understand usage of activity type concept better, let us look at Activity Class definition LENDING-DECREASE-TERM.AMOUNT. When you view the list of Activities that you can perform on an Arrangement, all Activities belonging to a particular Property Class (TERM.AMOUNT in this case) wil l 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.


170

We can see that in LENDING-AGE-OVERDUE activity class we have the activity types mentioned like if it is scheduled, secondary and sod process. We have some actions in property class that have user input as NO – This indicates that these actions in the property class will automatically triggered by the system and doesn’t need user intervention. The Can Prop Class, Can Action and Can user input indicates the actions that would be reversed when the activity is reversed and if user intervention is required for the same.


171

It is possible to create linked activity to AA.ACTIVITY which will perform exactly the same activity as the srcinal one. We would need linked activities when we have to differentiate between the same activity triggered by various OFS, channels or transaction codes – Eg: Deposit through branch, Foreign currency deposit through branch etc.


172

Hint : TERM.AMOUNT in filter, with LENDING


173

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.


174

There are five ways to do an arrangement activity.

Theyconditions can be runlike directly from the interest Arrangement Overview forchanging changingany terms and the loan term, changes, basically 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 asa “secondary activity”, triggered from another activity


175

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.


176

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.


177

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


178

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.


179

Use AA.ACTIVITY.HISTORY, with filter on arrangement ID, to see history of activities


180

A Personal loan with biweekly payments is chosen. We can see that there are few bills outstanding as per the schedules.


181

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


182


183

On clicking the new activity tab we have list of activity listed, Here chose to perform an activity, ensure the effective date is start date and validate the deal. We can see two tabs appear both Schedule and settlement instruction – Can you explain why both the tabs are appearing based on what we learnt about activities already? Yes Settlement instruction update is a secondary user triggered activities based on the schedule activity. Update the schedule tab as required. Now commit the record.


184

Open the Activity history record and view the reversal status.

Do you know why some activities are reversed and why some are not reversed.


185

Now open the record and authorise the same.


186

View the Activity history record to view the reversal authorised and new activity come up.


187


188

A personal loan arrangement is chosen with biweekly schedules. There are few bills outstanding.


189

The activity history is seen here for the arrangement.


190

The schedule is updated effective from the start date of the arrangement and the activity is committed.


191

We can see that some activities are in reversal states and the in unauth status. There are certain activities that are unaffected as well.


192

Delete the activity in un-auth status.


193

We can see the result as unauth activity being deleted and the reversal also deleted.


194

The record/arrangement returns back to srcinal schedule.


195


196

HINT: View Interest accruals: Use AA.INTEREST.ACCRUALS – filter ID contains , and PROPERTY.NAME contains PRINCIPALINT


197

We can see the Arrangement has an accrued interest for 6% under Prinicipalint component We can see the activity history. Interest accruals for principal interest in AA.INTEREST.ACCRUALS


198

We see the interest change activity is back dated and interest rate is changed,


199

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


200

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. Also can you see the effective accrual amount is changed in interest is correct even without reversal and replay.


201

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.


202

The User, in order to use the alerts features, has to make the ALERTS property class part of the PRODUCT.GROUPand 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.


203

Activity Presentations class is used for defining various versions to be used for different Property Classes / Properties / Activities during an arrangement entry. It helps in displaying various versions / screen while inputting an arrangement through browser for different Properties of the product. SUPPRESS.SEE.MODE - If the user wants to view only the property and its fields relevant to 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.


204


205

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.. Similarly data of simulated arrangements are stored in AA.SIM..


206

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.


207

Simulation within AA would require sub-systems. They are Simulation data capture and Simulation Runner. Simulation data capture captures data for activity being simulated subject to negotiation condition of the product. The data captured in simulation capture are stored in AA.SIM.. 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.


208

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.


209

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.


210

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.


211

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.


212

The pre-requisites for starting a simulation is detailed here. For R15 TAFJ area from Temenos Shell prompt type tRun START.TSM –DEBUG & tRun tSA **


213


214

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


215


217

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


Upon drilling down into the view button the simulation runner is seen. When executed successfully, we can find the record under the live file list.


219


220

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


221

Here, Simulations for comparison are chosen in AA simulation compare. 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.


222

1. c 2. b 3. b


223


224

Marketing Catalog is from the sales and marketing sense, something a customer would browse to look for the product that matches their requirements. Marketing focused product catalogue that can be exposed to all customer channels and provide an easy and intuitive mechanism by which bank staff and customers alike are able to quickly search for and locate the products they require. Each Product defined in the Product Catalogue (AA.PRODUCT) will have a corresponding Marketing Catalogue record which describes the key attributes and values for that product. This Marketing Catalogue will give the opportunity to the user/customer to compare different product based on criteria/fields defined by the Marketing Administrator of the bank. A new application AA.MARKETING.CATALOGUE.DESIGNER will be created to define the searchable parameters for each Product Group. Each record on this table will represent a Product.Group and the contents of the record will describe the searchable attributes and how they are to derived from the existing Product Catalogue data or whether they can be manually entered.


225

FIELD.NAME Name of the field ie Max.Loan.Amount or Early.Redemption.Penalty FIELD.DESCRIPTION Description of the field that will appear as a column header SOURCE.TYPE

Used to allow us to add multiple fields automatically in the case of interest and charge properties – ie rate, desc, etc. (See below fields of new table AA.STANDARD.FIELD.TYPE) SOURCE.PROPERTY

Contains the AA property name from which the source data is to be retrieved SOURCE.FIELD

Field on the defined property from which the data is retrieved (not allowed for source type interest or charge)

SRC.FLD.RULE.TYPE

Enable the user to decide if he wants to display the field value picked up in SOURCE.FIELD or if it needs to take it from a linked table (Periodic Rule, Negotiation Rule or Activity Restriction) SRC.FLD.RULE (‘Attributes’ column heading in version)


226

Define the rule from the previous RULE.TYPE you want to display (MINPERIOD, MAXMOUNT, etc…)


226

SOURCE.DATA.TYPE Indicates the data value type i.e. date, amount, rate etc. Could link to an IN2 routine (not allowed for source type interest or charge)

SOURCE.VALUE Enable to display a single value (text or number) that the user want to display for all products SOURCE.API Enable to connect to another system and get data that is not inside T24 SOURCE.NULL.VALUE Value to be applied if the property specified does not exist for a given product (not allowed for source type interest or charge)

ACTION This will allow the user to PUBLISH the marketing catalogue.


227

This Standard Field Type application used to define a standard set of fields to extract some standard information like interest and charge. Below standard set of fields would be defined for INTEREST in AA.STANDARD.FIELD.TYPE which will make-up interest information, like a. Whether interest rate is defined or not b. Type of interest, Fixed or Periodic or Floating c. Resolved interest rate (for key) or fixed interest rate d. Preferential rate for the customer e. Reset date for periodic or floating type interest Similarly below standard set of fields would be defined for CHARGE in AA.STANDARD.FIELD.TYPE which will make-up the charge information, like, a. Whether charge is defined or not b. Type of charge, Calculated or Fixed c. Charge rate in case of calculated d. Charge amount e. Preferential pricing amount for the customer These special data is only applicable for INTEREST and CHARGE properties.


228


229

Use Admin menu > Product Builder > Marketing Designer - Under

product line Lending Go to Small Business Loans – Click on edit icon After giving a meaningful name and description for the catalog being built, We define the criteria as minimum and maximum amount from COMMITMENT property with negotiation attributes as minimum and maximum. Similarly for the Term with minimum and maximum attribute from same property Interest is to be pulled out from the AA.STANDARD.FIELD.TYPE by indicating in SOURCE.TYPE The Catalog is to be published.


230

The marketing catalog is now commited. We can find the system data type for field names populated by the system


231

We find the conditions of the catalog built being displayed here.


232

In user menu, Retail operations, the catalogue created now is opened and the results are displayed.


233

To view the preferential information of Interest, we are using the customer 100100 and we see the preferential rates offered for this customer.


234


235

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


236


237

T24’s core accounting application provides the ability for an Account to hold and process multiple Balances. The Balances in AA are user defined subject to some rules, and they represent the financial components of an Arrangement. A Balance is specified by associating a Property with a Balance pre-fix . Of course, the Property should be a financial Property like ACCOUNT, INTEREST, CHARGE, etc. which allow Balances. You will learn in detail about how to do this later.

For example, a balance pre-fix of ‘Acc’ (for Accrued) can be associated with an interest property such as ‘PENALTYINTEREST’which will result in an ‘ACCPENALTYINTEREST’ balance. Different balances can be created for different Properties such as Committed Principal, Due Principal, due Penalty Interest, etc. Different Over Due balances can be created by its age like Overdue 5 days Principal Interest, Non Accrual Annual Fee, etc.

T24 Arrangement Architecture -Loans T3TAAL - R15

238

In this example, AA.INTEREST.ACCRUALS shows the total accrued penalty interest as USD 86.75. The total penalty accrued amount gets apportioned to each bill based on ACCRUAL.BY.BILLS in Penalty Interest Property.


239

In this example, the Property option has been set to only SUSPEND. You can see that interest accrual before NAB status are booked to P&L th

and when it reaches NAB on the 60 day, only future accruals are posted to SP balance while existing accruals are retained in P&L.


240

In this example, the Property option has been set to SUSPEND.OVERDUES. You can see that the interest accrual before NAB status are booked to P&L and when it reaches NAB on the 60 th day, the total accruals are reversed from P&L and placed to NABLOANINTSP and ACCLOANINTSP respectively and posts further accruals to Suspended balances.


241


242


243

T3TAAC Arrangement Architecture Core R15 v3.1

Recommend Documents