Arrangement Architecture- Product Builder

TEMENOS T24

Arrangement Architecture

Product Builder

User Guide

Information in this document is subject to change without notice.

No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of TEMENOS Holdings NV.

Copyright 2005 TEMENOS Holdings NV. All rights reserved.

Arrangement Architecture – Product Builder

Table of Contents

Introduction .............................................................................................................................................3 Application Overview...........................................................................................................................3

Product Builder and Catalogue ...............................................................................................................4 Overview..............................................................................................................................................4 Product Lifecycle .................................................................................................................................5 Product Definition Structure ................................................................................................................5

Property Classes and Product Lines (Temenos Defined) ...............................................................5 Properties and Product Groups .......................................................................................................6 Defined Properties .........................................................................................................................10

Product Designer ..................................................................................................................................21 Linking Properties and Conditions.....................................................................................................21 Assigning Defined Properties ............................................................................................................21 Product Inheritance (Families) ..........................................................................................................26

Arrangements........................................................................................................................................27 Opening an Arrangement ..................................................................................................................27 Relationship between Products and Arrangements ..........................................................................27 Changing Product..............................................................................................................................27 Dynamic Product Conditions .............................................................................................................27 Closing an Arrangement....................................................................................................................28

Product Catalogue ................................................................................................................................28 Publishing Products...........................................................................................................................28 Product Proofing................................................................................................................................29 Product Publishing.............................................................................................................................33

Arrangements........................................................................................................................................36 Opening an Arrangement ..................................................................................................................36 Further Activities on an Arrangement................................................................................................37

Batches and Jobs..................................................................................................................................38 Scheduled Activities ..........................................................................................................................38

Batch – AA.EOD.PROCESS .........................................................................................................43 Batch – AA.SOD.PROCESS .........................................................................................................43 Job - AA.SERVICE.PROCESS......................................................................................................43 Job - AA.COB.PAY.IN.OUT...........................................................................................................44

TEMENOS T24 User Guide Page 2 of 44


Introduction

Application Overview 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 main features of the AA module are:

• Ability to build families of products.

• Ability to inherit properties from the product family structure.

• Ability to determine the properties that a product is comprised of.

• Control of default values to be applied for product arrangements.

• Dated conditions for products.

• Full control of scope of negotiation between product and arrangement conditions.

• Control of negotiation of attributes over time.

• Design/Proof/Publish lifecycle for product management.

• The product builder can be used to create and maintain existing application (Mortgage, Account, Loans and Deposits and AZ) product parameters.

Please see the Introduction / Property Classes user guide for more details on individual classes.



Product Builder and Catalogue

Overview The Product Builder is constructed on the premise that all products are constituted from a number of fundamental business components defined in AA.PROPERTY.CLASS (see user guide for “Arrangement Architecture – Introduction / Property Classes). Each of these Property Classes consists of a number of conditions (e.g. interest rate, day basis, margin, etc.) which control the characteristics of a Product, and a number of actions, which control its processing.

For example, loan interest, deposit interest, penalty interest and commission all share the same basic conditions and actions and these should therefore all be described via a generic “Interest” Property Class. Within this “Interest” class, users have the ability to describe all of the characteristics and processing required to support any interest based characteristics of any product.

The advantage of this approach is that the Arrangement Architecture provides consistency and high levels of functionality across all products (e.g. if a loan can have tiered interest, then by default a credit card or savings account can also have tiered interest). Similarly, when we enhance our software to support a new Property Class feature, this capability becomes available across the whole system not just within a specific product line.

There are a finite number of Property Classes (e.g. Interest, Term Amount, Charge, Payment Schedule, Transaction Rules, etc.) which Temenos defines and combines to describe high-level product classifications or Product Lines defined in AA.PRODUCT.LINE (e.g. Lending, Deposits, Accounts, Credit Cards, etc.). It is these Product Lines, which are the basis for the creation of the products, which will be sold and serviced.

The Product Builder is hierarchical and allows the derivation of product structures from higher levels. For example, a Product (e.g. 15 year Fixed Rate Mortgage) will be derived from a Product Group (AA.PRODUCT.GROUP) (e.g. Mortgages), which will be derived from a Product Line (e.g. Lending).

Figure 1 T24 Product Builder Hierarchy.

In addition to this structural hierarchy, the Product Builder enables the definition of “families” of products through Product Inheritance. This allows for a derivative of a product to be defined by simply specifying a “parent” product and any different conditions. This approach offers rapid time-to-market for new products and simplified maintenance of related products.



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

Figure 2 Product Lifecycle.

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

Product Definition Structure

Property Classes and Product Lines (Temenos Defined) A Product Line is described by the Property Classes which constitute it and those which do not.

The “Lending” line and “Account” line will have a number of common classes such as “Interest” and “Charge” and at least one distinguishing class, which in the case of “Lending” could be an “Overdue” or “Credit Limit” class.

Figure 3 Example Lending vs. Account Product Lines

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



Properties and Product Groups While the Property Classes define the fundamental building blocks, a more specific classification is necessary to fully describe a product. For example a loan product may require more than one type of “Interest” (i.e. “normal interest” and “penalty interest”). To satisfy this requirement the Product Builder has a concept of a Property which is a named type of Property Class.

Example Properties of the “Interest” class would be “principal interest”, “penalty interest”, “credit interest”, “debit interest”, etc. Each of these Properties would share a common set of characteristics and processing. It is in fact these lower level Properties to which defined conditions (i.e. specific interest rates) are attached in order to create the products that are available for sale.

Penalty Interest Commission

Interest

Principal Interest

Figure 4 Example Interest Properties.

While the Property Classes are defined and released by Temenos, the underlying Properties are created and maintained by users. Any number of Properties can be defined providing an extremely powerful and flexible means of creating new innovative products. For example if a product type was desired that required three separate interest rates with different calculation methods the user would simply create (or reuse) the three Properties of an “Interest” Property Class.

The properties are defined in AA.PROPERTY.

Figure 5 AA.PROPERTY record for INTEREST.

The field PROPERTY.CLASS indicates which property class this property belongs to.



Each AA.PROPERTY.CLASS record is explained in full in the User Guide for Property Classes.

Some Properties, like Accounting are unlikely to be defined or modified at arrangement level. In such cases, it is possible to define them at product level only by selecting PRODUCT.ONLY in field PROPERTY.TYPE and thus ensuring that the details cannot be changed at arrangement level.

Once the necessary Properties have been created, the designer can use them to define a Product Group by specifying the mandatory and optional Properties which comprise it.

Figure 6 - Example Personal Loans Product Group.

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

Product groups are defined by the user in the application AA.PRODUCT.GROUP.



Figure 7 AA.PRODUCT.GROUP – Example.

The field GROUP.TYPE defines whether or not the product is for sale within the Bank (INTERNAL) or just as information or comparison only and not for sale (EXTERNAL).

The field PRODUCT.LINE indicates which AA.PRODUCT.LINE this product group belongs to. The system will check that all mandatory properties within the product line are defined within the AA.PRODUCT.GROUP and that any properties that are not defined within the product line record are not allowed within the AA.PRODUCT.GROUP. An error message will be generated if there are any discrepancies.



Figure 8 Error message showing validation against AA.PRODUCT.LINE.

The above error message was generated, because the CUSTOMER property class is mandatory within the AA.PRODUCT.LINE record for LENDING.

The associated multi value set of fields PROPERTY.CLASS, PROPERTY and MANDATORY are used to define the property class as defined in AA.PROPERTY.CLASS, the corresponding property from AA.PROPERTY and whether this property is mandatory or not.

The fields PROPERTY and MANDATORY can also be sub values so to include more than one property that corresponds to the property class.

In the example below, there are three types of interest that may be included within any product defined under the MORTGAGE product group.

Figure 9 Example of multi value fields PROPERTY.CLASS, PROPERTY and MANDATORY.

The LOANINTEREST property is mandatory whilst the two other INTEREST properties are not.



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

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

Figure 10 Example "Library" of Defined Properties.

Each property class record is linked to an application AA.PRD.DES.XXXX where XXXX is the ID of the property class. Values or default records are defined within these applications.

The ID for each of these records are defined by the selection of values in field TYPE in the associated AA.PROPERTY.CLASS record. For example if DATED is selected, the ID of the AA.PRD.DES.XXXX record will take the format of NNN-YYYYMMDD where NNN is any alphanumeric characters. If CCY is also selected, the ID will take the format of NNN-CCY-YYYYMMDD.

Each property class has different field values that are relevant to the type of property. For example, the conditions for the INTEREST property class are defined in AA.PRD.DES.INTEREST and the fields are all interest related.



Figure 11 AA.PRD.DES.INTEREST – Product condition record.

Similarly, the conditions for ACCOUNT are defined in AA.PRD.DES.ACCOUNT.



Figure 12 AA.PRD.DES.ACCOUNT – Product condition record.

For the ACCOUNT property class, some of the fields can be seen as above. It is unlikely that any of the fields for ACCOUNT will be defined at product level as the account is created when an arrangement is input and authorised. It is possible to have some default fields that may be changed or negotiated at arrangement level.



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

There are a group of fields on each property condition to define which fields are negotiable and to also define specific negotiation terms.

Figure 13 AA.PRD.DES.INTEREST – Negotiation Fields.

If any fields can be negotiated at arrangement level, field DEFAULT.NEGOTIABLE must be set to YES. This field is mandatory and the alternative option is NO.

It is possible to define all fields as negotiable and define an exception in field NR.ATTRIBUTE or vice versa. The field NR.ATTRIBUTE is part of a multi value set of fields which define any rules that may be linked to the field being negotiated.

These fields are used to define a single attribute and any negotiation rules that may apply to it. The name of the attribute (field) to be defined is entered into field NR.ATTRIBUTE.



Figure 14 AA.PRD.DES.INTEREST – Field FIXED.RATE defined with negotiation rules

Field NR.OPTIONS is a multi value field and has several options to define the field input into NR.ATTRIBUTE. The options are:

• FIX.VALUE - defines whether or not the field value will be fixed at the arrangement level. If a field is negotiated, the value is automatically fixed at arrangement level, but it is also possible that the value will not be negotiated, but should still be fixed.

• MANDATORY – a field that is not currently mandatory can become mandatory by selecting this option.

• NEGOTIABLE – the field input into NR.ATTRIBUTE is negotiable and can be subject to negotiation rules defined in the fields NR.STD.COMP through to NR.MESSAGE.

• NON-NEGOTIABLE – the field is not negotiable.

• OVERRIDE – an override will be generated if the field is negotiated.

To define rules for negotiation, fields NR.STD.COMP, NR.TYPE, NR.VALUE and NR.MESSAGE are used. In field NR.STD.COMP, the rules need to firstly be defined in application EB.STANDARD.COMPARISON so that they can be selected within the appropriate AA.PRD.DES.XXXX application and condition record.



Figure 15 EB.STANDARD.COMPARISON – Application for inputting negotiation rules

This application allows the user to define several rules together and can also include routines. Once the rule has been input and authorised, it will appear on the drop down list for the field NR.STD.COMP.

There are also pre-defined negotiation rules which are released by Temenos or can be created by the user in the application EB.COMPARISON.TYPE.



Figure 16 EB.COMPARISON.TYPE record –DIFFERENCE.

These record id’s can be utilized in field NR.TYPE. However, it is important to choose a rule that is applicable to the type of field.

For example, do not choose MULTIPLE for a field that does not relate to an amount.

The following is a sample list of some of the EB.COMPARISON.TYPE records.

Figure 17 Negotiation options in field NR.TYPE.



When choosing one of the negotiation rules in field NR.TYPE, a value must also be entered into field NR.VALUE. This value will be checked when the field is negotiated at arrangement level and if there is any discrepancy; an override or error message will be generated depending on the option selected in field NR.MESSAGE.

Periodic Rules Several Property Classes allow for the specification of Periodic Rules, allowing the product designers to specify restrictions on product conditions for certain periods of time (e.g. monthly, yearly, arrangement lifetime, etc).

As an example, a product may be specified as having an initial interest rate of 5% which can increase no more that 1% during each 12 month period and a total of 3% during the term of the arrangement. Similarly Periodic Rules can be used to specify transaction rules such as the number and value of withdrawals or disbursements allowed within a specified period or periods.

Similarly to negotiation rules, there are a group of fields in the application AA.PRD.DES.XXXX in which to define the periodic rules.



Figure 18 AA.PRD.DES.INTEREST – Periodic Rules.

The periodic rules are defined and released by Temenos in an application called AA.PERIODIC.ATTRIBUTE.CLASS. Each of these records is defined for certain AA.PROPERTY.CLASS records. For example, the AMOUNT.DECREASE record is defined to use with the TERM.AMOUNT Property Class to indicate how much of the principal may be decreased within a period of time.

Figure 19 AA.PERIODIC.ATTRIBUTE.CLASS records.



The User must then define further time constraints around the rules above in an application called AA.PERIODIC.ATTRIBUTE.

Figure 20 AA.PERIODIC.ATTRIBUTE record.

The field PR.ATTR.CLASS defines the AA.PERIODIC.ATTRIBUTE.CLASS record to base the rule upon.

This field PERIOD.TYPE represents the rule that needs to be applied on a specific period or life time of the contract.

• ACTUAL – A period of time must also be input into field PERIOD. This is expressed as either NND (Number of Days), NNW (Weeks), NNM (Months) or NNY (Years). Input into period is only allowed when using this option.

• LIFE – The comparison applies to entire life of the contract

• PRODUCT – The comparison applies to the contract when it is linked to a specific product.

It is possible to define the rules to apply to a defined period of time or to a specific calendar period.

For example, if today’s date is 15th January and the period is 3M:

If CALENDAR is YES the rule will apply to the period from 15th January to 31st March.

If the value is NO the rule will apply to the period from 15th January to 15th April.

The field BASE.DATE defines the date in the arrangement contract to use as the base date for calculating the period. The options are:

• None – This option must be selected if the PERIOD.TYPE is LIFE.



• Agreement Date – The date the arrangement was created.

• Start Date – The date the product started. If the product is changed this is the date the product changed.

• Today – Today’s date.

The AA.PERIODIC.ATTRIBUTE is linked to a property class in field PR.ATTRIBUTE in the appropriate AA.PRD.DES.XXXX record to specify the comparison value that applies for that property condition.

Figure 21 AA.PRD.DES.TERM.AMOUNT- Periodic Rules.

The value to be applied to the periodic attribute is input into PR.VALUE (e.g. the rule for maximum 1 month decrease is 10,000).

Using field PR.BRK.RES, the User can specify what action takes place when the rule is broken.

The options are:

• INFORMATION – Record the fact that the rule is broken only.

• OVERRIDE – Give an override.

• ERROR – Block processing with an error message.

• CAP – If the rule is broken an upper limit cap is applied.

• FLOOR – If the rule broken a lower limit floor is applied.

When an arrangement is created the periodic attribute value is available for modification at the arrangement level.



It is possible to apply a negotiation rule and attribute restriction in the same way as any other property attribute for a periodic attribute. Restrictions and negotiation should be applied to the value associated with the periodic rule.

Product Designer

Linking Properties and Conditions New products are designed within the application AA.PRODUCT.DESIGNER. The conditions and structure of these products can be modified at any time.

All new products must be associated to a product group so the product group should be defined in AA.PRODUCT.GROUP before any new product can be built.

Product records are identified with a key of

PRODUCT – EFFECTIVE DATE

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

Car LoanHome

Improvement Loan

Personal Loans

Tuition Loan

Lines of CreditMortgages

Figure 22 - Example of Products in the Personal Loans group.

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

Assigning Defined Properties To create a Product users link the desired Defined Properties (e.g. 5% flat rate) to the appropriate Properties (e.g. Principal Interest).



Figure 23 Defined Properties linked to Product.

It is possible to have several dated records for one product – this enables the user to change one or more of the conditions of the product as market conditions or other factors necessitate a change to the original product conditions.



Figure 24 AA.PRODUCT.DESIGNER – Example.

The field PRODUCT.GROUP defines which group the product belongs to and this group will previously have been defined in the application AA.PRODUCT.GROUP.

The field PARENT.PRODUCT indicates whether this product is derived from a parent product. If a product is input into this field, all of the properties and property conditions that have been defined within this product will be inherited by the child product. It is possible to override the condition of a certain property by defining an alternative condition within the child product.

During the product proofing process, the system will expand the properties inherited from the parent product along with any new properties defined in the child product and will check that all mandatory properties have been defined. It will also check that there are no property conditions defined for a property that is not included in the associated product group.

The currency in which this product will be sold is defined in field CURRENCY. This field is multi value to allow for more than one currency to be allowed.

The fields PROPERTY, PRD.PROPERTY, ARR.LINK and EFFECTIVE are a multi value set of mandatory fields. It is possible to define numerous property conditions using this set of fields.

The value entered input field PROPERTY would need to have been previously defined in application AA.PROPERTY. All properties that are defined as mandatory within the associated AA.PRODUCT.GROUP must be defined for each new product.

The field PRD.PROPERTY is used to define the condition for the property. The value entered here will be determined from the records created in the applications AA.PRD.DES.XXXX (where XXXX is the name of the Property Class).

It is only necessary to input the first part of the ID, i.e. if the ID is 99-USD-20030602 for an INTEREST property, it is necessary to input 99 only. If the product has been defined in more than one currency, during the proofing/publishing process the system will check that there are conditions defined for that ID for all currencies listed in field CURRENCY.

The field ARR.LINK defines whether the condition is NON.TRACKING, CUSTOMER.TRACKING or TRACKING.



Figure 25 AA.PRODUCT.DESIGNER – ARR.LINK.

NON.TRACKING - Once the arrangement has been opened, all conditions for a specific Property will be set for the duration of the arrangement. Subsequent changes to the “fixed” product conditions will not affect the arrangement.

TRACKING - The Product Conditions of a Property will contain values for all mandatory parameters. At the arrangement level the user cannot change any of the conditions of the Property. Throughout the duration of an arrangement any product level changes to a “tracking” property will be reflected in the arrangement.

CUSTOMER.TRACKING - This type of arrangement property behaves in a similar way to “tracking” properties except that individual conditions can be input (within negotiation limits) at the arrangement level. Any attributes, which have been input, will effectively become fixed for the duration of the arrangement. All other attributes will track changes at the product property.

The field EFFECTIVE represents the effective period after which a new property condition comes into effect. This allows a timed change of a condition for the product so that a property can be linked to one defined condition and switch to a different one after a specified period of time.

The field INHERITANCE.ONLY is used to define whether the product is allowed for sale or whether it is defined purely for inheritance purposes. If YES is selected, the product will not be for sale and is used purely by further child products. If NO is selected, this product will be able to be used in arrangements. It is not possible to input an arrangement using a product that has been defined as inheritance only.

The multi value group of fields CALC.PROPERTY, SOURCE.TYPE, SOURCE.BALANCE and SOURCE.PROPERTY relate to accounting.

For example, the interest may be calculated on the outstanding amount of the balance only. If this is the case, the interest property is entered into field CALC.PROPERTY and the SOURCE.TYPE



determines whether the interest is calculated on a BALANCE or PROPERTY. If the Balance is required, the corresponding record from AC.BALANCE.TYPE is entered into SOURCE.BALANCE.

Figure 26 AA.PRODUCT.DESIGNER.

As per most T24 applications it is possible to add multiple Local Reference fields to the AA.PRODUCT.DESIGNER record.

Changing Defined Properties As economic conditions change over time, the characteristics of products are likely to change. These changes will be entered as updated Defined Property records with new effective dates. This method allows a change to be scheduled for a future date. Additionally, back-dated changes can also be entered in the same fashion. A full history of all Defined Properties, which were applicable to a Product at any point in time, is available.

In addition to dated changes of a single Defined Property, the Product Builder also allows a Product to be defined with “timed” changes of its conditions. These timed changes are handled as either “product changes” (i.e. an introductory product is set for a given period after which the arrangement will revert to a standard product) or as “condition changes” (i.e. a standard product property is linked to one Defined Property and after a period of time switches to a different Defined Property.

The difference between the two types described above is that in the case of the product change, there are two defined products both of which exist independently. In the second example there is only one product whose conditions change after a given period.

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

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



Product Inheritance (Families) A key feature of the Product Builder is Product inheritance. This allows for the creation of product families where derivatives of a generic product or sub-product can be quickly created by simply defining the delta (in terms of product conditions) between the new and existing product. This means that where a Defined Property is not specifically defined it will be inherited from the parent product, grandparent product, etc.

For example a bank may wish to offer a range of car loans with rates varying based on the type of car and the term of the loan. A generic “car loan” product would be defined where all the standard terms and conditions such as base interest rate, max and min principal amounts, early redemption penalties and charges can be defined. The actual products to be sold can then be defined as derivatives of this base product where only the interest rate, term, and overdue processing change. For each derivative product it would only be necessary to specify the relevant Defined Properties that differ from the parent product.

Figure 27 - Product Inheritance

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



Arrangements

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

Relationship between Products and Arrangements The Product Builder will support a number of options in terms of how each arrangement will be affected by changes to its Product definition.

To provide the highest level of flexibility, each set of Product Conditions on a Product will be defined as fixed, tracking, or negotiable.

NON.TACKING – Once the arrangement has been opened, all conditions for a specific Property will be set for the duration of the arrangement. Subsequent changes to the “fixed” product conditions will not affect the arrangement.

TRACKING – The Product Conditions of a Property will contain values for all mandatory parameters. At the arrangement level the user cannot change any of the conditions of the Property. Throughout the duration of an arrangement any product level changes to a “tracking” property will be reflected in the arrangement.

CUSTOMER.TRACKING – This type of arrangement property behaves in a similar way to “tracking” properties except that individual conditions can be input (within negotiation limits) at the arrangement level. Any attributes, which have been input, will effectively become fixed for the duration of the arrangement. All other attributes will track changes at the product property.

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

Dynamic Product Conditions When defining an AA Product, users can specify rules-based dynamic product conditions. Examples of these rules include “Platinum vs. Standard Customer”, “Resident vs. Non-Resident”, “Internet vs. Branch”, etc. A user can then define a single Product as having different interest conditions if the customer is Platinum rather than Standard. When processing an arrangement, the rules-based selection of conditions is dynamic and is done every time the conditions are to be used.



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

Product Catalogue

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

This process is shown in the diagram below.

TERM

PRINCIPAL INTEREST

TERM.UCL3

PRIN.INT.UCL3

PRINCIPAL PRIN.UCL1

REPAYMENT

OVERDUE

REPAY.CL1

OD.CL1

PENALTY INTEREST PEN.INT.UCL1

PRINCIPAL

TERM

PRIN.CL1

PRINCIPAL INTEREST

REPAYMENT

OVERDUE

TERM.CL1

PRIN.INT.CL1

REPAY.CL1

OD.CL1

PRINCIPAL PRIN.UCL1

PRINCIPAL INTEREST

PENALTY INTEREST

PRIN.INT.UCL1

PEN.INT.UCL1

PRINCIPAL INTEREST

OVERDUE

PENALTY INTEREST

PRIN.INT.NCL1

OD.NCL1

PEN.INT.NCL1

TERM

PRINCIPAL INTEREST

TERM.UCL3

PRIN.INT.UCL3

TERM

PRINCIPAL INTEREST

TERM.UCL5

PRIN.INT.UCL5

Figure 28 Publishing diagram.

This will effectively allow the users to build and modify products without affecting the current banking operations. In fact the product building process will need to be a three-stage operation consisting of design, proof, and publish stages.



Once a product has been built and amended using the product designer it must move through a proofing stage before it can be published and made available for sale. The proofing stage performs the following:

• Expand the product definition to include the inherited property definitions from the published parent product (See Product Hierarchy).

• Ensure that the resolved product definition includes all mandatory properties identified in the Product Group definition.

• Ensuring that conditions exist for each property condition linked to a product.

• Ensuring that a currency condition exists for each allowed currency for the product.

• Cross-validating product property conditions to ensure consistency and avoid conflicting values.

Once reviewed, any further modifications made, and re-proofed the new products can be published. This will generate a new effective dated product record in the published product catalogue.

Product Proofing The product will be advanced through the stages of this lifecycle by using the AA.PRODUCT.MANAGER application.

The ID for this application is the name of the product to be proofed and subsequently published.

Figure 29 Example AA.PRODUCT.MANAGER record with action PROOF.

The fields AVAILABLE.DATE and EXPIRY.DATE indicate the period during which this product is for sale. The EXPIRY.DATE can be left at null to indicate that there is no specified end date for the sale of this product.

A value of PROOF in the field ACTION must first be selected and the record authorised.

Product proofing will use the current Product Designer definitions for the product to perform the proofing validation. The proofing process will return any errors found in the validation process and they will be listed in multi value field PRODUCT.ERROR.



Figure 30 AA.PRODUCT.MANAGER – Errors shown during Proofing process.

All errors must be resolved before moving on to the Publishing stage.

Figure 31 AA.PRODUCT.MANAGER with no errors in Proofing process.

Once the proofing process has been authorised, the proofed product records are held in the AA.PRODUCT.PROOF application which can be viewed only.

Product records are identified with a key of: PRODUCT – EFFECTIVE DATE



Figure 32 AA.PRODUCT.PROOF record.

As in the product designer a separate application for each property class is used to define the conditions. This application is called AA.PRD.PRF.XXXX where XXXX is the name of the property class.



Property condition records are identified with a key of:

Product - Property [- Currency] – Eff Date Option– Date

Where:

Product is the name of the product

Property is the name of the property.

Currency identifies the currency for which the definitions apply. Currency is only required if the Property Class is identified a CURRENCY type property and in this case is a mandatory element.

Eff Date Option Identifies the effective date option in the product definition (if any) for the property and associated condition

Date identifies the effective date for the defined conditions within that record.

AA.PRD.PRF.INTEREST – List of all records linked to Product MTG5YRFXD

It is also possible to view each individual record.



Product Publishing The product can be published once the proofing stage is successfully completed.

It will not be possible to PUBLISH a product that has any errors defined in field PRODUICT.ERROR.

Figure 33 AA.PRODUCT.MANAGER – Errors not cleared before Publishing.

When all errors have been resolved, it is possible to move on to the Publishing stage.

The value in field ACTION can now be changed to the value of PUBLISH and the record must then authorised.

Figure 34 AA.PRODUCT.MANAGER – Publishing a product.

Once this application has been authorised, the records in AA.PRODUCT.PROOF and AA.PRD.PRF.XXXX will be removed and AA.PRODUCT.CATALOG and AA.PRD.CAT.XXXX will be updated.

Published product records will be held in the AA.PRODUCT.CATALOG application which can be viewed only. This application will show all of the conditions that are linked to the product including any conditions that have been inherited from a parent product.



Figure 35 Example AA.PRODUCT.CATALOG record.

The published record will be written to this file. Prior to publishing, all previous records for this product will be removed. The published records will be held with the key PRODUCT – EFFECTIVE DATE



As in the product designer a separate application for each property class is used to define the conditions. This application is called AA.PRD.CAT.XXXX where XXXX is the name of the property class.

Property condition records are identified with a key of:

Product - Property [- Currency] – Date

Where:

Product is the name of the product.

Property is the name of the property.

Currency identifies the currency for which the definitions apply. Currency is only required if the Property Class is identified a CURRENCY type property and in this case is a mandatory element.

Date identifies the effective date for the defined conditions within that record.

The record ids derived and stored in the proofing phase will be used in the publishing stage.

Further information is also held in the AA.PRODUCT application which can be viewed only. This table holds details of all currently published products. A single record for each product will hold basic details including the status of the product, the dates the product is available for use and also the properties that are linked to the product.

Figure 36 Example AA.PRODUCT record.

Once a product is published the entire product and condition records are made available for use with arrangements of that product type. Any previously published records are superseded by the new published records.



Arrangements

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

Input into AA.ARRANGEMENT.ACTIVITY

Figure 37 New AA.ARRANGEMENT.ACTIVITY record.

When inputting a new arrangement, enter NEW into field ARRANGEMENT. Clicking on the validate button will show the list of available activities. For a new arrangement, the ACTIVITY will be LENDING-NEW-ARRANGEMENT.

The PRODUCT field will list all products that have been through the publishing process and on selection will default any conditions from the product.



Once the AA.ARRANGEMENT.ACTIVITY record has been authorised, an AA.ARRANGEMENT record is system generated. This record can be viewed only and holds the details of the Arrangement Number and also the Account Number.

Further Activities on an Arrangement All further activities on the arrangement will use the Arrangement Number from AA.ARRANGEMENT.

A new AA.ARRANGEMENT.ACTIVITY record is called up and the Arrangement Number is input into field ARRANGEMENT

The dropdown list in field ACTIVITY shows all of the activities available to the product. An EFFECTIVE DATE should be input, but all other details, such as CUSTOMER and CURRENCY will default from the original Arrangement.



Batches and Jobs

Scheduled Activities Arrangement activities are processed using the AA.ARRANGEMENT.ACTIVITY application and these can be initiated in a number of ways:

• User initiated request.

• Non AA-Transaction initiated – for example when crediting or debiting an arrangement account from an existing application.

• As a scheduled process – the activity should be processes automatically according to a some schedule defined for the product or arrangement.

Some activities may be initiated in more than one way. The valid initiation types are defined in the AA.ACTIVITY.CLASS definition which is released by TEMENOS. The definition is contained in the ACTIVITY.TYPE field. The initiation method of activities is pre-defined and cannot be amended.

Scheduled activities will be processed as part of the Close of Business (COB) and specific BATCH records are released with the relevant jobs required to perform the contract processing.

Figure 38 Activty Class showing Activity Type.

Sequence of Activities in Batch Processes Several activities may be scheduled to be processed for an arrangement on the same date, the sequence the activities are performed in is important and this is defined as part of the AA.ACTIVITY.CLASS definition.

Each BATCH process that should perform the scheduled activity is specified in the AA.ACTIVITY.CLASS record together with a numeric sequence which is used to determine the order that the activities will be executed for an arrangement.

The definition of the batch and sequence is pre-defined and cannot be amended.



Figure 39 Activity Class Showing Batch Link and Sequence.

Add enquiry showing sequence for a product

Arrangement Contract Scheduled Activities Arrangement contracts for products that have scheduled activities will maintain a list of scheduled activities to be performed for that arrangement together with the next scheduled event date and the last time it was performed.

These details are maintained in AA.SCHEDULED.ACTIVITY. The details are updated as part of the activity processing for arrangement property maintenance and the scheduled activity itself. E.g. the creation of a new loan contract will update the next scheduled MAKEDUE activity when the PAYMENT.SCHEDULE is initially defined or subsequently modified, The MAKEDUE activity itself will cycle forward to the next due date and ensure that AA.SCHEDULED.ACTIVITY reflects this.

Figure 40 AA.SCHEDULED.ACTIVITY for an arrangement.



Add poss. arr level enquiry

Accrual Frequency Activities such as Accrual and Amortisation perform internal accounting processing (i.e. the booking of P&L) rather than actions that relate to the customer of the contract. The frequency for performing these activities does not form part of the product definition and is instead controlled by a central accrual frequency definition in AA.ACCRUAL.FREQUENCY.

A single definition will exist for each financial company that will allow the frequency to be defined at the following levels for properties that can be accrued:

1. For a specific property of a specific product.

2. For a specific property in any product.

3. For any property.

For each of theses combinations different frequencies can be defined for local and foreign currency contracts.

The following frequency options are allowed for accrual:

• DAILY – The accrual processing will take place for each CALENDAR day. I.e. on a Friday COB for a normal weekend there will be 3 accrual activities processed for a contract.

• BSNSS – The accrual processing will take place for each business day. i.e. on a Friday COB for a normal weekend there will be 1 accrual activity for a contract that covers the period Friday – Sunday inclusive.

• Mnndd – The accrual is performed every nn months on the dd day of the month. If 31 is defined as the day this indicates that processing must take place on the last day of the month.

• Null – No accrual is to be processed on scheduled basis at all.

Only properties that belong the INTEREST or CHARGE Property Classes can be defined in AA.ACCRUAL.FREQUENCY.



Figure 41 Accrual Frequency Definition in AA.ACCRUAL.FREQUENCY.

Example

In the above example the following frequencies would be applied:

• Product HIGHVALUELOAN.

o Interest property CURRINT for local currency contracts is accrued monthly on the 15th of the month.

o Interest property CURRINT for foreign currency contracts is accrued on a daily basis.

o Interest property PENALTYINT for local currency contracts is accrued monthly on the 15th of the month.

o Interest property PENALTYINT for foreign currency contracts is accrued daily.

• Any product other than HIGHVALUELOAN using PENALTYINT interest property.

o local currency contracts are accrued monthly on the last day of the month.

o foreign currency contracts are accrued daily.

• Any other interest property or product.

o Local currency contracts perform no scheduled accrual.

o Foreign contracts are accrued quarterly on the last day of the month.

Activities that determine their processing frequency as scheduled tasks are defined in the AA.ACTIVITY.CLASS record. The field ACTIVITY.TYPE will contain ACCRUAL to indicate this. This is pre-determined and cannot be modified.



Figure 42 Example of Activity Class Definition for Accrual.

Processing the Activity When a scheduled activity is processed an AA.ARRANGEMENT.ACTIVITY transaction will be performed the transaction request will contain the arrangement number, required activity and effective date for the request. The effective is the actual date that the activity should be processed on.

The activity request is performed by the TSA service running the process through OFS. Scheduled activities are processed without the need to separate authorisation, in the case of processing error or exception the activity request will left in HLD status and can be completed manually. The detail of error and exception (e.g. override) processing will depend on the operation of the specific activity.

For frequently repeated activities such as accrual the same AA.ARRANGEMENT.ACTIVITY transaction will be used for each scheduled event. For all other scheduled activities separate AA.ARRANGEMENT.ACTIVITY transactions will be generated.

It will be possible to reverse scheduled activity requests after the scheduled activity has taken place (subject to any restrictions that a specific activity may have).

Transaction Management For each arrangement and processing date the system will process all scheduled activities together. Activities will be performed in the correct sequence and will form a single database transaction, Any error or failure of an activity will mean that all activities for that arrangement and processing date will not be processed.



Batch – AA.EOD.PROCESS This performs arrangement processing in the End of Day section of the close of business. The Batch is defined for each Financial company in a multi-company implementation and runs in the system wide section of the close of business.

The following processes are run as part of this batch:

• Processing of Payments in and out of arrangement accounts generated as part of the close of business.

• Processing of scheduled activities for the products.

Batch – AA.SOD.PROCESS This performs arrangement processing in the Start of Day section of the close of business. The Batch is defined for each Financial company in a multi-company implementation and runs in the start of day section of the close of business.

The following processes are run as part of this batch:

• Processing of Payments in and out of arrangement accounts generated as part of the close of business.

• Processing of scheduled activities for the products.

Job - AA.SERVICE.PROCESS

Description This job performs the processing of all scheduled activities. The process will check for all current arrangement contracts to see if there a scheduled activity due to be processed as part of the Close of Business.

Activities will be processed by generating AA.ARRANGEMENT.ACTIVITY records as described above.

When run in the End of Day close of business this process will be repeated for each calendar date between and including the current system date and the period end date. For each processing date all contracts will be processed.

When run in the Start of Day close of business the process will only be perfomed in the case of a month end (i.e. the last working day was in the previous month). The processing will be repeated for each calendar date between and including the 1st day of the month up to the calendar date before the current system date.

Technical Details The selection of contracts is driven from the internal table AA.NEXT.ACTIVITY. This contains one record for each arrangement contract with the contract number and next scheduled activity date of any type, it is maintained with the AA.SCHEDULED.ACTIVITY table. A filter routine is used to ensure that only arrangements with an activity due for that process date, or with a possible accrual frequency are added to the JOB.LIST for processing.




Job - AA.COB.PAY.IN.OUT

Description This job will submit and complete processing of AA.ARRANGEMENT.ACTIVITY requests generated by non-AA transactions during close of business. During close of business processing the payment transactions will generate AA.ARRANGEMENT.ACTIVITY requests in HLD status.

The processing will check all AA.ARRANGEMENT.ACTIVITY records in HLD status that are for activities relating to payment types. Payment Type activities are identified by the definition of ACCOUNTING in the ACTIVITY.TYPE of the underlying ACTIVITY.CLASS.

The requests are submitted to OFS in zero authoriser mode. In the case of error or override the transaction will remain in HLD status and must be processed manually.

Technical Details The AA.ARRANGEMENT.ACTIVITY $NAU table is selected.

The record processing will determine that:

• The record status is HLD.

• The activity is a payment type.

If both cases are true then the activity will be processed.

Documents

Arrangement Architecture- Product Builder