Arrangement Architecture – Introduction / Property Classes

TEMENOS T24
Arrangement Architecture
Property Classes

User Guide

Information in this document is subject to change without notice.

TEMENOS T24 User Guide Page 1 of 183
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 – Introduction / Property Classes

Table of Contents
Overview .................................................................................................................................................. 9 
Product Builder .................................................................................................................................... 9 
Arrangements ...................................................................................................................................... 9 
Product Lines Available ..................................................................................................................... 10 
Property Classes ............................................................................................................................... 11 
ACCOUNT.............................................................................................................................................. 11 
Overview ............................................................................................................................................ 11 
Property Product Relationship ........................................................................................................... 11 
Related Balances .............................................................................................................................. 12 
Property Attribute Description and Use ............................................................................................. 13 
Property Details ................................................................................................................................. 15 
Periodic Attribute Classes associated with Account ......................................................................... 19 
Action Synopsis ................................................................................................................................. 19 
Accounting Events ............................................................................................................................. 20 
Limits Interaction ............................................................................................................................... 20 
Delivery .............................................................................................................................................. 20 
ACCOUNTING ....................................................................................................................................... 21 
Overview ............................................................................................................................................ 21 
Property Product Relationship ........................................................................................................... 21 
Related Balances .............................................................................................................................. 22 
Summary of Rules Based Accounting ............................................................................................... 22 
Property Attribute Description and Use ............................................................................................. 26 
Property Details ................................................................................................................................. 30 
Periodic Attribute Classes associated with Accounting..................................................................... 30 
Action Synopsis ................................................................................................................................. 30 
Accounting Events ............................................................................................................................. 30 
Limits Interaction ............................................................................................................................... 31 
Delivery .............................................................................................................................................. 31 
ACTIVITY MAPPING ............................................................................................................................. 32 
Overview ............................................................................................................................................ 32 
Property Product Relationship ........................................................................................................... 32 
Related Balances .............................................................................................................................. 33 
Property Attribute Description and Use ............................................................................................. 33 
Property Details ................................................................................................................................. 35 
Periodic Attribute Classes associated with Activity Mapping ............................................................ 35 
Action Synopsis ................................................................................................................................. 35 

TEMENOS T24 User Guide Page 2 of 183

Arrangement Architecture – Introduction / Property Classes

Accounting Events ............................................................................................................................. 35 

Limits Interaction ............................................................................................................................... 35 
Delivery .............................................................................................................................................. 35 
ACTIVITY.API ........................................................................................................................................ 36 
Overview ............................................................................................................................................ 36 
Property Product Relationship ........................................................................................................... 36 
Periodic Attribute Classes associated with Activity Api ..................................................................... 38 
Action Synopsis ................................................................................................................................. 38 
Accounting Events ............................................................................................................................. 38 
Limits Interaction ............................................................................................................................... 38 
Delivery .............................................................................................................................................. 38 
ACTIVITY.CHARGES ............................................................................................................................ 39 
Overview ............................................................................................................................................ 39 
Property Product Relationship ........................................................................................................... 39 
Periodic Attribute Classes associated with Activity Charges ............................................................ 41 
Action Synopsis ................................................................................................................................. 41 
Accounting Events ............................................................................................................................. 41 
Limits Interaction ............................................................................................................................... 41 
Delivery .............................................................................................................................................. 41 
ACTIVITY.MESSAGING ........................................................................................................................ 43 
Overview ............................................................................................................................................ 43 
Property Product Relationship ........................................................................................................... 43 
Related Balances .............................................................................................................................. 44 
Summary of Rules Based Delivery.................................................................................................... 44 
Configuring T24 Delivery for an AA Product ..................................................................................... 47 
Property Details ................................................................................................................................. 57 
Periodic Attribute Classes associated with Activity Messaging......................................................... 58 
Action Synopsis ................................................................................................................................. 58 
Accounting Events ............................................................................................................................. 58 
Limits Interaction ............................................................................................................................... 58 
Delivery .............................................................................................................................................. 59 
ACTIVITY.PRESENTATION .................................................................................................................. 60 
Overview ............................................................................................................................................ 60 
Product Property Relationship ........................................................................................................... 60 
Periodic Attribute Classes associated with Activity Presentation ...................................................... 62 
Action Synopsis ................................................................................................................................. 62 
Accounting Events ............................................................................................................................. 62 

TEMENOS T24 User Guide Page 3 of 183

Arrangement Architecture – Introduction / Property Classes

Limits Interaction ............................................................................................................................... 62 

Delivery .............................................................................................................................................. 62 
CHANGE.PRODUCT ............................................................................................................................. 63 
Overview ............................................................................................................................................ 63 
Property Product Relationship ........................................................................................................... 63 
Property Attribute Description and Use ............................................................................................. 64 
Loan Renewal .................................................................................................................................... 65 
Periodic Attribute Classes associated with Change Product ............................................................ 78 
Action Synopsis ................................................................................................................................. 78 
Accounting Events ............................................................................................................................. 78 
Limits Interaction ............................................................................................................................... 79 
Delivery .............................................................................................................................................. 79 
CHARGE ................................................................................................................................................ 80 
Overview ............................................................................................................................................ 80 
Property Product Relationship ........................................................................................................... 80 
Periodic Attribute Classes associated with Charge........................................................................... 87 
Action Synopsis ................................................................................................................................. 88 
Accounting Events ............................................................................................................................. 88 
Limits Interaction ............................................................................................................................... 88 
Delivery .............................................................................................................................................. 88 
CUSTOMER ........................................................................................................................................... 89 
Overview ............................................................................................................................................ 89 
Property Product Relationship ........................................................................................................... 89 
Periodic Attribute Classes associated with Customer ....................................................................... 91 
Actions Synopsis ............................................................................................................................... 91 
Accounting Events ............................................................................................................................. 91 
Limits Interaction ............................................................................................................................... 91 
Delivery .............................................................................................................................................. 91 
INTEREST.............................................................................................................................................. 92 
Overview ............................................................................................................................................ 92 
Property Product Relationship ........................................................................................................... 92 
Periodic Attribute Classes associated with Interest ........................................................................ 100 
Action Synopsis ............................................................................................................................... 100 
Accounting Events ........................................................................................................................... 101 
Limits Interaction ............................................................................................................................. 101 
Delivery ............................................................................................................................................ 101 
LIMIT .................................................................................................................................................... 103 

TEMENOS T24 User Guide Page 4 of 183

Arrangement Architecture – Introduction / Property Classes

Overview .......................................................................................................................................... 103 

Property product Relationship ......................................................................................................... 103 
Periodic Attribute Classes associated with Limit ............................................................................. 105 
Action Synopsis ............................................................................................................................... 105 
Accounting Events ........................................................................................................................... 105 
Delivery ............................................................................................................................................ 105 
OFFICERS ........................................................................................................................................... 106 
Overview .......................................................................................................................................... 106 
Property product Relationship ......................................................................................................... 106 
Action Synopsis ............................................................................................................................... 108 
Accounting Events ........................................................................................................................... 108 
Limits Interaction ............................................................................................................................. 108 
Delivery ............................................................................................................................................ 108 
OVERDUE............................................................................................................................................ 109 
Overview .......................................................................................................................................... 109 
Property Product Relationship ......................................................................................................... 109 
Periodic Attribute Classes associated with Overdue....................................................................... 115 
Action Synopsis ............................................................................................................................... 115 
Accounting Events ........................................................................................................................... 116 
Limits Interaction ............................................................................................................................. 116 
Delivery ............................................................................................................................................ 116 
PAYMENT.RULES ............................................................................................................................... 117 
Overview .......................................................................................................................................... 117 
Property Product Relationship ......................................................................................................... 117 
Periodic Attribute Classes associated with Payment Rules ............................................................ 120 
Action Synopsis ............................................................................................................................... 120 
Accounting Events ........................................................................................................................... 121 
Limits Interaction ............................................................................................................................. 121 
Delivery ............................................................................................................................................ 121 
PAYMENT.SCHEDULE ....................................................................................................................... 122 
Overview .......................................................................................................................................... 122 
Property Product Relationship ......................................................................................................... 122 
Periodic Attribute Classes associated with Payment Schedule ...................................................... 127 
Action Synopsis ............................................................................................................................... 127 
Accounting Events ........................................................................................................................... 127 
Limits Interaction ............................................................................................................................. 127 
Delivery ............................................................................................................................................ 127 

TEMENOS T24 User Guide Page 5 of 183

Arrangement Architecture – Introduction / Property Classes

TERM AMOUNT .................................................................................................................................. 128 

Overview .......................................................................................................................................... 128 
Product Property Relationship ......................................................................................................... 128 
Related Balances ............................................................................................................................ 129 
Property Attribute Description and Use ........................................................................................... 130 
Periodic Attribute Classes associated with Term Amount............................................................... 132 
Action Synopsis ............................................................................................................................... 137 
Accounting Events ........................................................................................................................... 138 
Limits Interaction ............................................................................................................................. 138 
Delivery ............................................................................................................................................ 138 
ACTIVITY.RESTRICTION.................................................................................................................... 139 
Overview .......................................................................................................................................... 139 
Property Product Relationship ......................................................................................................... 139 
Periodic Attribute Classes associated with Activity Restriction ....................................................... 141 
Action Synopsis ............................................................................................................................... 151 
Accounting Events ........................................................................................................................... 151 
Limits Interaction ............................................................................................................................. 151 
Delivery ............................................................................................................................................ 151 
PAYOFF ............................................................................................................................................... 152 
Overview .......................................................................................................................................... 152 
Property Product Relationship ......................................................................................................... 152 
Related balances ............................................................................................................................. 153 
Property Attribute Description and Use ........................................................................................... 153 
Generating payoff bill....................................................................................................................... 154 
Periodic attribute classes associated with Pay off .......................................................................... 158 
Activity class related to payoff property class.................................................................................. 159 
Action synopsis................................................................................................................................ 160 
Accounting Events ........................................................................................................................... 160 
Delivery ............................................................................................................................................ 160 
SETTLEMENT ..................................................................................................................................... 161 
Overview .......................................................................................................................................... 161 
Product Property Relationship ......................................................................................................... 161 
Property Attribute Description and Uses ......................................................................................... 162 
Synopsis of Actions ......................................................................................................................... 169 
PROTECTION.LIMIT ........................................................................................................................... 170 
Overview .......................................................................................................................................... 170 
Property Product Relationship ......................................................................................................... 170 

TEMENOS T24 User Guide Page 6 of 183

Arrangement Architecture – Introduction / Property Classes

Action Synopsis ............................................................................................................................... 171 

Accounting Events ........................................................................................................................... 171 
Limits Interaction ............................................................................................................................. 171 
Delivery ............................................................................................................................................ 171 
UI.APPEARANCE ................................................................................................................................ 172 
Overview .......................................................................................................................................... 172 
Property Product Relationship ......................................................................................................... 172 
Action Synopsis ............................................................................................................................... 173 
Accounting Events ........................................................................................................................... 173 
Limits Interaction ............................................................................................................................. 173 
Delivery ............................................................................................................................................ 173 
UI.BEHAVIOUR ................................................................................................................................... 174 
Overview .......................................................................................................................................... 174 
Property Product Relationship ......................................................................................................... 174 
Action Synopsis ............................................................................................................................... 175 
Accounting Events ........................................................................................................................... 175 
Limits Interaction ............................................................................................................................. 175 
Delivery ............................................................................................................................................ 175 
USER.RIGHTS ..................................................................................................................................... 176 
Overview .......................................................................................................................................... 176 
Property Product Relationship ......................................................................................................... 176 
Action Synopsis ............................................................................................................................... 177 
Accounting Events ........................................................................................................................... 177 
Limits Interaction ............................................................................................................................. 177 
Delivery ............................................................................................................................................ 177 
PROXY.PERMISSIONS....................................................................................................................... 178 
Overview .......................................................................................................................................... 178 
Property Product Relationship ......................................................................................................... 178 
Action Synopsis ............................................................................................................................... 179 
Accounting Events ........................................................................................................................... 179 
Limits Interaction ............................................................................................................................. 179 
Delivery ............................................................................................................................................ 179 
PRODUCT.ACCESS............................................................................................................................ 180 
Overview .......................................................................................................................................... 180 
Property Product Relationship ......................................................................................................... 180 
Action Synopsis ............................................................................................................................... 181 
Accounting Events ........................................................................................................................... 181 

TEMENOS T24 User Guide Page 7 of 183

Arrangement Architecture – Introduction / Property Classes

Limits Interaction ............................................................................................................................. 181 

Delivery ............................................................................................................................................ 181 
ARRANGEMENT.PREFERENCES ..................................................................................................... 182 
Overview .......................................................................................................................................... 182 
Property Product Relationship ......................................................................................................... 182 
Action Synopsis ............................................................................................................................... 183 
Accounting Events ........................................................................................................................... 183 
Limits Interaction ............................................................................................................................. 183 
Delivery ............................................................................................................................................ 183 

TEMENOS T24 User Guide Page 8 of 183

Arrangement Architecture – Introduction / Property Classes

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:

Product Builder
The application provides the ability to allow the user to construct banking products by combining
different business components. PRODUCT.LINES which provide functionality for different banking
areas are licensed by Temenos; each product line utilises a number of property classes (business
components) that are fully configurable.

Main features of the product builder are:

• Ability to build families of products.
• Ability to inherit properties from the product family structure.
• Ability to determine the properties that a product is comprised of.
• Control of default values to be applied for product arrangements.
• Dated conditions for products.
• Full control of scope of negotiation between product and arrangement conditions.
• Control of negotiation of attributes over time.
• Design/Proof/Publish lifecycle for product management.
• The product builder can be used to create and maintain existing application (Mortgage,
Account, Loans and Deposits and AZ) product parameters.

Please see the Product Builder user guide for more details.

Arrangements
An arrangement is an agreement between the bank and interested party to provide an agreed service.
The AA module provides the ability to manage arrangements for created products.

Main features of arrangements are:

• An arrangement is an instance of the product.
• The arrangement properties and attributes may track the product conditions (i.e. change
when the product definition is amended).

TEMENOS T24 User Guide Page 9 of 183

Arrangement Architecture – Introduction / Property Classes

• The arrangement properties and attributes may be fixed based on the product definition at
creation time.
• The arrangement property attributes may be negotiated / override the product definition
according to product defined rules.

Product Lines Available

The following PRODUCT.LINES are available which utilise the AA framework. Each product line
requires a licence to be obtained from Temenos to allow building and use of products.

RETAIL.LENDING
The AL module provides a fully flexible retail lending functionality for T24. The module allows retail
products to be created with the following features:
• Full support for commitment processing.
• Unlimited interest types including penalty interest.
• Unlimited charge types.
• Fully integrated rules based overdue and aging processing.
• Ability to amend / reverse / update arrangements back dated with full automatic recalculation
and adjustment of contract.
• Ability to pay in and disburse the arrangement through any T24 application and channel that
allows the specification of a T24 account. As a result disbursal and Repayment can be from
accounts in any currency.
• Fully flexible repayment schedule.
• Flexible production of bills when repayments are due.
• Ability to overpay / underpay / pay late or early based on issued bills.
• Utilises rules based accounting allowing flexible configuration of entry / balance generation in
T24.

INTERNET SERVICES – ARC Internet Banking

The AI module provides the ability for the bank to provide full internet banking services for individual
clients.
Please see the ARC-IB Administration user guide for more details.

PROXY.SERVICES – ARC Proxy Services

The AP module provides extended internet access to T24 banking services. This product can be
purchased in addition to the INTERNET.SERVICE product and allows organisations to manage their
banking operations through T24.
Please see the ARC-IB Administration user guide for more details.

TEMENOS T24 User Guide Page 10 of 183

Arrangement Architecture – Introduction / Property Classes

Property Classes
The AA.PROPERTY.CLASS definitions are released by Temenos and cannot be amended with the
exception of the description fields.
Financial institution can use these “building blocks” of functionality to construct the individual products
which are available for sale to its customers.
The current release of classes are described below in there relevant sections.

ACCOUNT
Overview
The ACCOUNT Property Class is used by all AA products which are account based and will therefore
result in the creation of an associated account record for an arrangement of the product.
This property class manages the descriptive and classification details of the Arrangement and is used
in the creation and maintenance of the account record that is related to the arrangement.

Product Lines
The ACCOUNT property is used by the following product lines:
• LENDING
• DEPOSITS
• ACCOUNTS

Property Product Relationship

The ACCOUNT product property supports the following arrangement links to the product:

• DATED

All attributes in the Account property are therefore stored at the arrangement level and do not track
the underlying product.

TEMENOS T24 User Guide Page 11 of 183

Arrangement Architecture – Introduction / Property Classes

ACCOUNT Property Class record.

Related Balances
The Account property has associated financial balances that reflect the arrangement principal in the
various stages of the arrangement life-cycle.
The following balances can exist for the property:

Current Principal Balance

For a loan contract the current principal reflects the amount that has been disbursed and is not yet
due to be repaid.
The current principal is identified with a prefix of CUR.

Due Principal Balance

For a loan contract the due principal reflects the amount of the loan that has been disbursed and is
now due for repayment.
The due principal is identified with a prefix of DUE.

TEMENOS T24 User Guide Page 12 of 183

Arrangement Architecture – Introduction / Property Classes

Aged Principal Balance

For a loan contract the aged principal balance reflects the due amounts of the loan that has aged
according to the stages defined in OVERDUE property condition.
DUE balances are aged when the date since the bill that generated the due balance passes the
number of days specified in the OVERDUE property condition. The billed balance assumes the
associated status defined in the condition record. For a single arrangement there may be several
aged and due balances reflecting the different age of the outstanding bills.
The aged principal balance is identified with a prefix of the associated status in the OVERDUE
property.

Unallocated Credit Balance

The unallocated credit balance reflects general credits made to the arrangement. This balance is also
used to hold payments made against future or issued bills in advance of the due date. If the practice
(defined in PAYMENT.RULES property) requires that advanced payments do not repay current
principal then the repayment amount is allocated to the unallocated credit balance.
The unallocated credit balance is identified with a prefix of UNC.

Unallocated Debit Balance

The unallocated debit balance reflects general debits made to the arrangement.
The unallocated debit balance is identified with a prefix of UND.

Property Attribute Description and Use

Account Definition at Product Level
Reporting Classification
In an AA Product, the CATEGORY is used for reporting (i.e. balance sheet) purposes only. Usually a
category will be allocated to a specific product or family of products, although this is not mandatory.

Generic Arrangement Titles and Names

Although account names are typically account specific, generic titles can be defaulted from the
product in field ACCOUNT.TITLE and can be replaced or given additional detail at the arrangement
level. It is possible to enter up to two lines of up to 35 characters.
Field SHORT.TITLE is typically an abbreviation of the account title and is used throughout T24 as
enrichment.

Currency Market and Position Type

The CURRENCY.MARKET of an Arrangement can currently only be set to 1 and POSITION.TYPE can
be set only to TR.

TEMENOS T24 User Guide Page 13 of 183

Arrangement Architecture – Introduction / Property Classes

Account Definition at Arrangement Level

Currency
The CURRENCY of the arrangement is set from the New Arrangement Activity and stored on this field,
and cannot be modified.

Arrangement Reporting Classification

The CATEGORY can be amended if required at the arrangement level.

Arrangement Titles and Names

ACCOUNT.TITLE and SHORT.TITLE is defaulted from the product definition and can be overridden if
allowed by the product attribute control settings. CUSTOMER.REFERENCE allows a reference know by
the customer of the arrangement to be specified for information.

Alternate References
The following options are available for specifying alternate access references for the account:

• Field MNEMONIC is an alternate key which can be defined by a user to reference the account.
Typically this would be a memorable name for the arrangement.

Field ALTERNATE.ID is a multi-valued field in ACCOUNT.PARMETER which is linked to the

ALT.ACCT.PARAMETER file where alternative references can be specified.
Typically this is used to record other references that the arrangement may also be referred to by; for
example the previous reference of the contract in a legacy system, or the national account standard
account number (e.g. the BGC account number in the Netherlands) or the international account
number (e.g. the IBAN reference).
The ALT.ACCT.PARAMETER file controls and validates the alternate id reference which are stored in
the field ALT.ACC.ID on the ACCOUNT record.

For a more detailed explanation of this set-up please see the ACCOUNTS user guide.

Posting Restrictions
At the arrangement level, a posting restriction code (defined in POSTING.RESTRICT) can be used to
restrict the following:

• All Debits
• All Credits
• All Transactions
An override will be required to accept any entry which meets the conditions of a Posting Restriction.

TEMENOS T24 User Guide Page 14 of 183

Arrangement Architecture – Introduction / Property Classes

Repayment Restrictions
The field BASE.DATE.TYPE will be used by AA to calculate several of the other DATE fields of the
arrangement and will accept values of AGREEMENT or START (AGREEMENT is the default).
The option of AGREEMENT will result in the other dates being calculated based upon the effective
date of the NEW-ARRANGEMENT activity. The option of START will result in the other dates being
recalculated when the DISBURSE activity occurs.

A field ANNIVERSARY can be used to store the anniversary of the account for restriction purposes and
its value is stored in the format MM DD.

In conjunction with restrictions this field can also used for general configuration across all
AA.PERIODIC.ATTRIBUTES classes.

Local References Mapping

Only the contents of the local reference fields populated in the underlying condition records
AA.PRD.DES.ACCOUNT are mapped to the associated local reference fields in the ACCOUNT
record when the AA.ARRANGEMENT is created.

Property Details
Creation of T24 Account
When a financial arrangement is created the system will generate a T24 account record. The account
record generated will be allocated a standard T24 account number according to the rules defined in
the COMPANY application.
Note: In order for the arrangement module to be able to generate an account record the ACCOUNT
application must be configured to generate ids automatically.
The Account record is built by mapping the relevant fields from the DEPT.ACCT.OFFICER,
CUSTOMER, ACCOUNT and LIMIT properties of the arrangement into the layout of the account
record (for technical details of this process see: xxx).
The ACCOUNT record created cannot be modified directly using the ACCOUNT application,
instead the associated properties must be modified using the appropriate maintenance activities from
AA.ARRANGEMENT.ACTIVITY.

The ACCOUNT record holds the arrangement number in the ARRANGEMENT.ID field.
Arrangement account records behave slightly differently to standard T24 accounts:

• There is no CONDITION.GROUP allocated

• The interest and charges module does not apply to these accounts.

TEMENOS T24 User Guide Page 15 of 183

Arrangement Architecture – Introduction / Property Classes

ACCOUNT record with ARRANGEMENT.ID stored.

This account number linked to the arrangement is stored in the AA.ARRANGEMENT record.

TEMENOS T24 User Guide Page 16 of 183

Arrangement Architecture – Introduction / Property Classes

AA.ARRANGEMENT showing ACCOUNT number.

Using the Arrangement Account in Other T24 Applications

In order to pay funds into or withdraw funds from an arrangement any existing T24 application that
allows an Account to be defined can be used, for example FUNDS.TRANSFER or TELLER.
In the application the user can specify the account number itself, the mnemonic, any alternate
account id linked or the arrangement number when the arrangement is in the same company as the
transaction. If the arrangement account is to be used in an application in a different financial company
to the arrangement then the actual account number is the only option allowed.

TEMENOS T24 User Guide Page 17 of 183

Arrangement Architecture – Introduction / Property Classes

Note: In order to be able to specify the arrangement number or an Alternate Account Number the field
ALTERNATE.ACC.IDS must be set to Y in ACCOUNT.PARAMETER.

ACCOUNT.PARAMETER with ALTERNATE.ACC.IDS set.

The FUNDS.TRANSFER application can be used to draw down and commit to an amount of the
arrangement. The DEBIT.ACCT.NO field is used to debit the ACCOUNT record associated to the
AA.ARRANGEMENT.

FUNDS.TRANSFER used to draw down a committed amount.

TEMENOS T24 User Guide Page 18 of 183

Arrangement Architecture – Introduction / Property Classes

Periodic Attribute Classes associated with Account

There are no periodic attributes available for use with the ACCOUNT property

Action Synopsis
The ACCOUNT Property supports the following actions:
CREDIT
The credit action applies the unallocated amount from a credit to the arrangement to the unallocated
credit balance of the arrangement.

DEBIT
The debit action applies the unallocated amount from a debit to the arrangement to the unallocated
debit balance of the arrangement.

DISBURSE
The disburse action is used when a loan is disbursed. The action will result in the current balance of
the account property being debited.

MAINTAIN
The maintain action is used whenever one of the properties linked to the T24 ACCOUNT record
(CUSTOMER, DEPT.ACCT.OFFICER, LIMIT, ACCOUNT) is modified. The action does not
generate any accounting movement but updates the related T24 ACCOUNT record to reflect the
values for the arrangement property.
It is this ACTION that will result in the creation of a T24 arrangement account when the NEW-
ARRANGEMENT activity is processed.

A scheduled MAINTAIN account activity LENDING-MAINTAIN-ACCOUNT will be raised for the future
effective date that will be processed in the Start Of Day of the effective date. The MAINTAIN activity
will update the ACCOUNT record with the future dated changes.

MAKE.DUE
The make due action will apply the amount of principal due to be repaid to the DUE account property
balance and will reduce the CURrent account property by the amount to be made due.
The amount to be made due is determined from the associated BILL that is being made due.

REPAY
The repay action will allocate an amount of principal to be repaid to the appropriate account balance.
Depending on the PAYMENT.RULE applied the repayment will be made against billed or current
amounts.

TEMENOS T24 User Guide Page 19 of 183

Arrangement Architecture – Introduction / Property Classes

Processing determines the amount and balance to be credited based on the PAYMENT.RULE
definition and can result in credit being applied to the CUR, DUE or AGEd balances of the account
property.

UPDATE
The update action is used to apply the changes to the ACCOUNT property attributes and does not
result in any accounting updates.

Other ACTIONS supported are CAPTURE.BILL, ADJUST.BILL, RESIDUAL, AGE.BILLS and

ADVANCE.REPAY.

Accounting Events
The following actions generate accounting events as defined in field ACCOUNTING.
• CREDIT
• DEBIT
• DISBURSE
• MAINTAIN
• MAKE.DUE
• REPAY
• CAPTURE.BILL
• ADJUST.BILL
• RESIDUAL
• AGE.BILLS
• ADVANCE.REPAY

Limits Interaction
The ACCOUNT property does not directly interact with the LIMITS system in T24 but the associated
arrangement ACCOUNT record is closely linked.
The LIMIT Property condition specifies the LIMIT.REFERENCE to be used for the arrangement
product and this is the limit reference used in the related ACCOUNT record.

Delivery
No special processing for the ACCOUNT class in delivery

TEMENOS T24 User Guide Page 20 of 183

Arrangement Architecture – Introduction / Property Classes

ACCOUNTING
Overview
The AA module utilises T24 rules based accounting to generate its accounting movements.
The ACCOUNTING Property Class is used by all financial products and controls the link between the
accounting events generated by the property actions and the accounting allocation rules to be applied
to these events.
Users can specify accounting rules for each Property which has Actions that require accounting.

Product Lines
The ACCOUNTING property is used by the following product lines:

LENDING
DEPOSITS
ACCOUNTS

Property Product Relationship

The ACCOUNTING product property supports the following arrangement links to the product:

• DATED
• MERGE
• TRACKING.ONLY

The property cannot be defined at arrangement level.

The ACCOUNTING property is mandatory for all financial product lines.

TEMENOS T24 User Guide Page 21 of 183

Arrangement Architecture – Introduction / Property Classes

ACCOUNTING Property Class record.

Related Balances
The accounting property does not have any financial balances associated with the property.

Summary of Rules Based Accounting

The AA module uses rules based accounting to control the accounting movement generation. Via the
soft accounting set-up system, the actual accounting entries are generated / updated in T24 at given
actions and events per Property.
An overview of the mechanism and relationships with properties is described here.

Actions and Accounting Events

Actions performed by properties on an arrangement can result in the movement of one or more
balances associated with that property. When a balance movement is required the action will
generate an accounting event.

TEMENOS T24 User Guide Page 22 of 183

Arrangement Architecture – Introduction / Property Classes

The accounting event contains basic details of the change to the balance such as:

• Affected Balance
• Movement Amount
• Movement Sign
• Event (or Value) Date
• Arrangement Id
• Initiating Transaction Reference

In AA processing each event is always targeted to an arrangement balance (which must be defined in
the AC.BALANCE.TYPE table).

For each BALANCE.PREFIX value defined in AA.PROPERTY.CLASS record ACCOUNT, a unique

AC.BALANCE.TYPE record needs to be defined for accounting purposes.
The id’s of these records are made up from a combination of these BALANCE.PREFIX values and the
AA.PROPERTY id’s associated with the account class.

An example of this set-up can be seen below.

The AA.PROPERTY.CLASS record ACCOUNT has the following BALANCE.PREFIX defined.

ACCOUNT Property Class with BALANCE.PREFIX defined.

An AA.PROPERTY record of LOANACCOUNT is then associated to the above account class.

TEMENOS T24 User Guide Page 23 of 183

Arrangement Architecture – Introduction / Property Classes

AA.PROPERTY record LOANACCOUNT.

For this combination of set-up the following AC.BALANCE.TYPE records need to be established.

AC.BALANCE.TYPE records associated to LOANACCOUNT.

The records prefixed GRA, NAB, OD1 and OD2 relate to the overdue property and these need to be
defined for each overdue status.

TEMENOS T24 User Guide Page 24 of 183

Arrangement Architecture – Introduction / Property Classes

AC.BALANCE.TYPE record CURLOANACCOUNT.

The individual AC.BALANCE.TYPE records can then each be configured as required.

Allocation Rules
Each event raised by the action is the basis for generation of actual accounting entries. In T24 three
types of accounting entries can be generated from a single accounting event, these are:

STMT.ENTRY – a movement to a T24 account optionally with a specific balance type. Accounts can
be customer, internal or Nostro accounts.
CATEG.ENTRY – a profit and loss movement with a specific profit and loss category.
RE.CONSOL.SPEC.ENTRY – a movement to the arrangement contract with a specific balance type.

Each entry generated has a TRANSACTION code that is used to identify the type of movement
generated.
An allocation rule is used to specify the types of entry and target account, balance type or profit and
loss category that the event should generate. It also specifies how the details of the entry record are
to be built including the transaction code to be used.

TEMENOS T24 User Guide Page 25 of 183

Arrangement Architecture – Introduction / Property Classes

Allocation rules are defined in the table AC.ALLOCATION.RULE.

Entry Details
Each accounting entry contains a number of detailed fields. This contains information used by system
in financial reporting and also in production of customer statements and other enquiries.
Certain details in the entries generated as a result of the application rules can be configured, for
example:

• System Id
• Customer Narrative
• Customer References
• Internal References

The source and value of these details is specified in the table AC.POSTING.DETAIL which in turn
is linked to the AC.ALLOCATION.RULE table.

The soft accounting configuration is therefore flexible enough so any given accounting can be
generated at any given event time.

Link Between Property Accounting Events and Allocation Rules

The ACCOUNTING property is used to define the link between an ACTION for a Property product and
the AC.ALLOCATION.RULE to be applied to the events generated by an action.
The property therefore allows the format, target and detail of accounting movements to be configured
according to the product.

Property Attribute Description and Use

Linking an Action to an Allocation Rule
As described each action can generate a number of accounting events.
For each Property the allocation rule to be applied with each ACTION should be specified using the
sub-valued fields ACCT.ACTION and ACCT.RULE.

Re-use of the Same Accounting Property Condition

It is likely that the same accounting property conditions will be shared between multiple products
which may not be in the same product group. The PROPERTY field can contain properties that may not
be used in a product, using this facility a single record could be defined that can be used by all
products.
Alternatively a number of accounting conditions can be defined and the publishing process will merge
the content of the parent product condition with the record to be published.

TEMENOS T24 User Guide Page 26 of 183

Arrangement Architecture – Introduction / Property Classes

An example of soft accounting set up and entries generated at contract level.

The AC.POSTING.DETAIL application and its defined contents is used to control the mapping of
values i.e. references and narratives of accounting entries like STMT.ENTRY, CATEG.ENTRY and
RE.CONSOL.SPEC.ENTRY.

AC.POSTING.DETAIL record STMT-AA.

The above record relates to STMT.ENTRY records being created for AA and is in turn linked to the
AC.ALLOCTION.RULE rules table. This table is used to define accounting events used by the soft
accounting processing where the event is used to identify mapping tables to determine the type of
accounting entries to raise and the content of these entries.

TEMENOS T24 User Guide Page 27 of 183

Arrangement Architecture – Introduction / Property Classes

Example AC.ALLOCATION.RULE record.

In this table Debit and Credit TRANSACTION codes, ACCOUNT.CLASS records and
AC.POSTING.DETAIL records are all combined to create a catch all for each accounting event.
If required and depending on individual configuration different tables can be created for different
classes and purposes i.e. Interest or Overdue.

The AC.ALLOCATION.RULE tables are then linked to the product condition records per Property
as shown in the example below.

TEMENOS T24 User Guide Page 28 of 183

Arrangement Architecture – Introduction / Property Classes

Product condition record linking all related tables.

The PROPERTY field and its associated fields ACCT.ACTION and ACCT.RULE are used to define all
the underlying property class that are capable of creating accounting events. Each ACTION value as
defined in AA.PROPERTY.CLASS can be allocated in these multi-value set of fields.

TEMENOS T24 User Guide Page 29 of 183

Arrangement Architecture – Introduction / Property Classes

Once the product has been published by AA.PRODUCT.MANAGER these are the accounting
rules that the contracts will now ad-ea to.

Property Details
Publishing - Merging property conditions
With standard business property classes (e.g. INTEREST), a Defined Property defined for a ‘Child
Product’ will override a Defined Property specified for a ‘Parent Product’. The ACCOUNTING property
will allow merging of conditions between the child and parent product at the time of publishing.
When published, the ACCOUNTING Property Class is merged with the published parent definition as
follows:

• The Parent Record is taken as the base record.

• Property definitions in the child record will override the parent record definition if already defined.
• Child property definitions that do not appear in the parent record will be added to the base record.

Publishing Validation and Errors

At publishing time the system will apply the following specific validation to the accounting property to
be published:

• All properties and associated actions that result in the generation of accounting events must be
specified in the property definition

Periodic Attribute Classes associated with Accounting

There are no periodic attributes available for use with the ACCOUNTING property.

Action Synopsis
The ACCOUNTING Property supports the following actions:
UPDATE
The UPDATE action is initiated manually and allows the User to change any of the ACCOUNTING
attributes. This action will be initiated as part of the NEW-ARRANGEMENT and UPDATE-ACCOUNTING
activities and will amend the accounting rules.

Accounting Events
There are no accounting events generated by the actions of the ACCOUNTING property.

TEMENOS T24 User Guide Page 30 of 183

Arrangement Architecture – Introduction / Property Classes

Limits Interaction
The ACCOUNTING property does not perform any actions that impact on the limits system.

Delivery
The ACTIVITY.MESSAGING property class controls the T24 delivery events that are generated.

TEMENOS T24 User Guide Page 31 of 183

Arrangement Architecture – Introduction / Property Classes

ACTIVITY MAPPING
Overview
The ACTIVITY.MAPPING property class provides a link between financial transactions initiated in T24
outside of the AA module and the activity that should be processed against the arrangement.
Any application that raises an accounting to a T24 ACCOUNT can be used to pay funds in or out of
an AA Arrangement. The activity processed is mapped to the TRANSACTION code used in the T24
application accounting in this Property Class.

Product Lines
The ACTIVITY.MAPPING property is used by the following product lines:

• LENDING
• DEPOSITS
• ACCOUNTS

Property Product Relationship

The ACTIVITY.MAPPING product property has the following TYPE definitions:

• DATED
• TRACKING.ONLY
• MERGE

The property class is used to define the mapping rules from T24 TRANSACTION to AA.ACTIVITY,
this definition can only be defined at the Product Level and is not available for configuration at the
arrangement level.

TEMENOS T24 User Guide Page 32 of 183

Arrangement Architecture – Introduction / Property Classes

ACTIVITY.MAPPING Property Class record.

Related Balances
The ACTIVITY.MAPPING property does not have any related financial balances.

Property Attribute Description and Use

Linking non-AA Transactions to Property Activities
The method of paying in and out of an arrangement is to debit or credit the related T24 ACCOUNT
through any T24 application that allows specification of an account number.
Typical methods of disbursement of a loan arrangement could be a debit through the
FUNDS.TRANSFER application, a debit made through the TELLER application or through an ATM.
A typical repayment method could be a credit through the FUNDS.TRANSFER or TELLER
applications. Payment could be generated as a manual transaction or as a scheduled activity (e.g. a
standing order or cash pool sweep).
When a movement is posted to the related T24 ACCOUNT the system determines the activity to
perform against the arrangement based on the TRANSACTION code of the accounting movement.
The accounting property allows a TRANSACTION code to be linked to a specific AA.ACTIVITY.

TEMENOS T24 User Guide Page 33 of 183

Arrangement Architecture – Introduction / Property Classes

For example the TRANSACTION code 408 being posted across an Arrangement should result in the
AA.ACTIVITY LENDING-DISBURSE-ARRANGEMENT being generated.
Default debit and credit activities can be defined and will be used when a specific TRANSACTION
code in an accounting entry is not found in the accounting property.

Only a limited list of activities can be specified for the DEFAULT.CR.ACTIVITY,

DEFAULT.DR.ACTIVITY and TXN.ACTIVITY. These are indicated by the TYPE in the
AA.ACTIVITY.CLASS, that underlies the AA.ACTIVITY record.
In order to be able to specify the ACTIVITY the following TYPE definition must be present in
AA.ACTIVITY.CLASS:

• TXN.ACTIVITY – DEBIT or CREDIT

• DEFAULT.DR.ACTIVITY – DEBIT
• DEFAULT.CR.ACTIVITY – CREDIT

Activity Mapping Definition.

Disbursal of an Arrangement Loan

Funds are disbursed for an arrangement using existing T24 applications as described earlier in this
section. A Disbursal for a loan is a debit to the arrangement account and should be mapped using the
TRANSACTION code and TXN.ACTIVITY or the DEFAULT.DR.ACTIVITY.

Repayment of an Arrangement Loan

Funds are repaid for an arrangement using existing T24 applications as described earlier in this
section. A repayment for a loan is a credit to the arrangement account and should be mapped using
the TRANSACTION code and TX.ACTIVITY or the DEFAULT.CR.ACTIVITY.

TEMENOS T24 User Guide Page 34 of 183

Arrangement Architecture – Introduction / Property Classes

Property Details
Publishing - Merging property conditions
With standard business property classes (e.g. INTEREST), a Defined Property defined for a ‘Child
Product’ will override a Defined Property specified for a ‘Parent Product’. The ACTIVITY.MAPPING
property will allow merging of conditions between the child and parent product at the time of
publishing.
When published, the ACTIVITY.MAPPING Property Class is merged with the published parent
definition as follows:

• The Parent Record is taken as the base record.

• Property definitions in the child record will override the parent record definition if already defined.
• Child property definitions that do not appear in the parent record will be added to the base record.

Periodic Attribute Classes associated with Activity Mapping

There are no periodic attribute classes for the ACTIVITY.MAPPING property class.

Action Synopsis
The ACTIVITY.MAPPING Property supports the following actions

UPDATE
The UPDATE action is used to apply product level ACTIVITY.MAPPING definition to an arrangement
contract and is initiated as part of the NEW-ARRANGEMENT and UPDATE-ACTIVITY.MAPPING
activities.

Accounting Events
There are no accounting events generated by the ACTIVITY.MAPPING property class.

Limits Interaction
There is no interaction with the T24 Limit system by the ACTIVITY.MAPPING property.

Delivery
There is no special delivery processing required by the ACTVITY.MAPPING property.

TEMENOS T24 User Guide Page 35 of 183

Arrangement Architecture – Introduction / Property Classes

ACTIVITY.API
Overview
The ACTIVITY API Property Class allows users to extend the core processing of the Arrangement
Activities. In most respects it replaces the concept of adding user defined routines to Versions. User
defined processing is now specified by Product and benefits from Product Inheritance. Additionally, as
each Arrangement Activity is comprised of one or more Actions, this API methodology provides a high
degree of flexibility as user defined routines can be executed throughout an activity.

Product Lines
The ACTIVITY.API property is used by the following product lines:

• LENDING
• DEPOSITS
• ACCOUNTS
• INTERNET.SERVICES

Property Product Relationship

The ACTIVITY.API product property supports the following arrangement links to the product:

• DATED
• TRACKING.ONLY
• MERGE

TEMENOS T24 User Guide Page 36 of 183

Arrangement Architecture – Introduction / Property Classes

AA.PROPERTY.CLASS record.

Defining the ACTIVITY.API at Product Level

A single Action can be used within multiple Activities. A User must specify the activity context within
which a routine is to be executed. Either an ACTIVITY.CLASS or ACTIVITY.ID must be entered
along with either the PROPERTY.CLASS or the PROPERTY.
The ACTION is a mandatory field. Within the Activity Class or Activity the user must specify an
ACTION, and one or more Record, Pre or/and Post routines. These routines must be defined in
EB.API.

Processing API Routines

During the processing of an Arrangement Activity, T24 determines whether any API routines should
be executed prior to or after any of the Actions. As ACTIVITY API is a cumulative Property Class, the
system will process all of the routines specified using the following order of precedence:
• Record routines after the arrangement property records are built with the product condition and
arrangement data, but before the validations take place.
• Pre routines followed by Post Routines.

TEMENOS T24 User Guide Page 37 of 183

Arrangement Architecture – Introduction / Property Classes

• Highest to Lowest by Product Level (e.g. Grand Parent routines, Parent routines, Child routines).
• Activity Class followed by Activity routines within each level.

Periodic Attribute Classes associated with Activity Api

There are no periodic attribute classes for the ACTIVITY.API property class.

Action Synopsis
The ACTIVITY.API Property supports the following actions:
UPDATE
The UPDATE action is initiated manually and allows the User to change any of the ACTIVITY.API
attributes. This action will be initiated as part of the NEW-ARRANGEMENT and UPDATE-ACTIVITY.API
activities and will result in modification of the API rules.

Accounting Events
The ACTIVITY.API property does not perform any actions that generate accounting events.

Limits Interaction
The ACTIVITY.API property does not perform any actions that impact on the limits system.

Delivery
The ACTIVITY.MESSAGING property class controls the T24 delivery events that are generated.

TEMENOS T24 User Guide Page 38 of 183

Arrangement Architecture – Introduction / Property Classes

ACTIVITY.CHARGES
Overview
The ACTIVITY.CHARGES Property Class is used by any products which require charging for various
Arrangement Activities.

Product Lines
The ACTIVITY.CHARGES property is used by the following product lines:

• LENDING
• DEPOSITS
• ACCOUNTS

Property Product Relationship

The ACTIVITY.CHARGES product property supports the following arrangement links to the product:

• DATED
• TRACKING

TEMENOS T24 User Guide Page 39 of 183

Arrangement Architecture – Introduction / Property Classes

ACTIVITY.CHARGE Property Class record.

Defining the ACTIVITY.CHARGES at Product Level

ACTIVITY.CHARGES enables the linking of CHARGE Properties (which must exist on the Product) to
specific Activities. When the Activity defined in ACTIVITY.ID is processed, any charge amount
which has been specified in the field CHARGE will be billed immediately and made due according to
the period specified in the DUE field.

Capitalisation of Activity Charges

It is possible to allow an activity charge to be capitalised rather than be made due. A bill will be issued
immediately for the charge. Capitalisation will take place after a specified period from the issue of the
charge bill. The same can be specified by the fields APP.PERIOD and APP.METHOD.
APP.PERIOD specifies the period after which the capitalisation / make-due should happen from the
issue of the bill. APP.METHOD can hold values DUE or CAPITALISE. Here is where, whether the
activity charges is to be capitalised or to be made due, is mentioned.

TEMENOS T24 User Guide Page 40 of 183

Arrangement Architecture – Introduction / Property Classes

Activity charges can be capitalised or made due.

Periodic Attribute Classes associated with Activity Charges

There are no periodic attribute classes for the ACTIVITY.CHARGES property class.

Action Synopsis
The ACTIVITY.CHARGES Property supports the following actions:
UPDATE
The update action is initiated manually and allows the User to change any of the ACTIVITY.CHARGES
attributes. This action will be initiated as part of the NEW-ARRANGEMENT and UPDATE-
ACTIVITY.CHARGES activities and will result in the modification of activity based charge rules.

Another ACTION supported is CALCULATE.

Accounting Events
The ACTIVITY.CHARGES property does not perform any actions that generate accounting events.

Limits Interaction
The ACTIVITY.CHARGES property does not perform any actions that impact on the limits system.

Delivery
The ACTIVITY.MESSAGING property class controls the T24 delivery events that are generated. The
ACTIVITY.CHARGES property class generates delivery information as defined in field
DEL.INFO.REQD.

TEMENOS T24 User Guide Page 41 of 183

Arrangement Architecture – Introduction / Property Classes

ACTIVITY.CHARGES with DEL.INFO.REQD defined.

TEMENOS T24 User Guide Page 42 of 183

Arrangement Architecture – Introduction / Property Classes

ACTIVITY.MESSAGING
Overview
The ACTIVITY MESSAGING Property Class is used to link the production of T24 delivery events with
any activity that can be performed on an arrangement contract.
The T24 delivery system is a rules based system that allows creation of messages that can be sent
through any supported carrier medium (Printed, Fax, SWIFT, Email etc). Activities performed by
applications (in this case AA.ARRANGEMENT.ACTIVITY) can generate one or more message
types according to the configured rules.
The delivery system allows messages to be routed and formatted according to the type of message,
and also allows the option to create a deal slip.
The interface to the T24 delivery system allows the application to generate a delivery event. The
delivery event associates an activity identification code (ACTIVITY.CODE) with unformatted related
application data; a message reference allocated by the T24 delivery system is returned.

Product Lines

The ACTIVITY.MESSAGING property is used by the following product lines:

• LENDING
• DEPOSITS
• ACCOUNTS
• INTERNET.SERVICES
• PROXY.SERVICES

The ACTIVITY.MESSAGING property is OPTIONAL for all product lines.

Property Product Relationship

The ACTIVITY.MESSAGING product property supports the following arrangement links to the product:

• DATED
• TRACKING
• MERGE

The property cannot be defined at arrangement level and rules are always assigned from the product
definition.

TEMENOS T24 User Guide Page 43 of 183

Arrangement Architecture – Introduction / Property Classes

ACCTIVITY.MESSAGING Property Class record.

Related Balances
The ACTIVITY.MESSAGING property has no related balances.

Summary of Rules Based Delivery

The following section gives an overview of the T24 delivery system configuration, for full details
please refer to the T24 delivery user guide.

Delivery Message Types

Basic message types are identified in the DE.MESSAGE application. A numeric message identifier
is used to identify the type of message to be produced. For each message to be produced a number
of possible data fields are defined that together make up the content of the message.
A single message type may be generated by many different applications.

TEMENOS T24 User Guide Page 44 of 183

Arrangement Architecture – Introduction / Property Classes

Delivery Mapping
The DE.MAPPING application allows the raw delivery handoff data generated from the application
delivery event to be mapped to the field content defined in the DE.MESSAGE table. For each
different application (and possibly sub-division within application) the map between the handoff data
and required data layout must be defined.

Delivery Formatted Output

A formatting application will exist for some formatted output to allow the final layout of the message
based on field definition, position and conversion options. Examples include DE.FORMAT.PRINT
and DE.FORMAT.SWIFT.

Soft Delivery
Rules based (or soft) delivery allows one or more delivery message types to be generated from a
single delivery event.
The application generates the delivery event with an identifying code the ADVICES code together with
a collection of unformatted data from the underlying application – referred to as the delivery handoff
data.
The application EB.ADVICES is used to define the type, formatting and additional content of the
delivery messages to be generated. The key to the EB.ADVICES table is the advice code allocated
by the application. In the case of AA the advice code is allocated according to the
ACTIVITY.MESSAGING property.

EB.ADVICES allows definition of:

• Message type – DE.MESSAGE to be generated.

• Mapping record DE.MAPPING to be used to map the data from the application to the message
format.
• A specific printed format code to be used in the key to DE.FORMAT.PRINT for printed advices.
• Whether a Deal Slip should be produced in addition or instead of a delivery advice.
• An API to allow additional information to be created and include in the delivery handoff.

Application Handoff Format

The application will generate a delivery event including the following information:

• Advices code.
• Advice identifier code.
• Activity details.

TEMENOS T24 User Guide Page 45 of 183

Arrangement Architecture – Introduction / Property Classes

• Send Message Indicator.

• Data Handoff Details – 9 fixed handoff records can be created and an unlimited number of named
handoff records can be created.

Named Handoff Records

In order to manage the flexible structure of the AA module the ability to create named data handoff
records has been added. In order to use this facility the application must provide a list of named
records in one of the fixed data handoff records.
The data records associated with the named list area also handed off by the application.
The fixed record containing the list of names must be specified in the DE.MAPPING record field
RECORD.NAME.LOC.

The INPUT.REC.NO field in DE.MAPPING should be configured with the handoff record name and
the associated INPUT.FILE should be specified.

Definition of Output Carrier

The message carrier type to be used for the message production is defined in the table
DE.PRODUCT. This allows the DE.CARRIER (e.g. PRINT, SWIFT, EMAIL etc) to be allocated to
specified message types and optionally by customer and linked account.
The ENQUIRY DE.MSG.LINK can be used to show the messages that have been produced by an
arrangement

Example of Messages for an Arrangement.

TEMENOS T24 User Guide Page 46 of 183

Arrangement Architecture – Introduction / Property Classes

Configuring T24 Delivery for an AA Product

Content of Delivery Handoff
Any delivery event created from the AA application will generate the following delivery handoff data:
Handoff Record / Name Field Description
Number
1 AA.ARRANGEMENT record
2 AA.ARRANGEMENT.ACTIVITY record contains the
details of the activity request
3 AA.ACCOUNT.DETAILS – for financial arrangements
this contains a summary of the status and number of
outstanding bills
4 Hard coded details required for creation of the
delivery header and other mandatory message
information.
4 1 COMPANY of the arrangement
4 2 Currency of the arrangement
4 3 Account Officer / Department code of the
arrangement
4 4 AA Arrangement Activity Id
4 6 The customer of the arrangement
4 7 The CUSTOMER.COMPANY of the company of the
arrangement
4 8 The language of the customer
5 The CUSTOMER record for the customer of the
arrangement
6 The ACCOUNT record linked to the arrangement
7 List of property names handed off. This will contain
all properties apart from those where the
PROPERTY.CLASS definition denotes that the
property details should not be included.
Details are in the format <x> = Property
propertyName The content of each property record for the
arrangement activity effective date is included in the
handoff under the propertyName.
The order of the properties is defined in record 7

Note: you can view the content of the delivery handoff using the standard delivery ENQUIRY
DE.HANDOFF.DETS.

TEMENOS T24 User Guide Page 47 of 183

Arrangement Architecture – Introduction / Property Classes

Excluding Certain Properties from the Handoff

Certain properties are unlikely to be required in the content of delivery messages produced from AA,
for example the system management property classes such as ACCOUNTING, ACTIVITY.API and
ACTIVITY.MESSAGING.
The field DEL.INFO.REQD on AA.PROPERTY.CLASS is used to indicate that any property of this
class should be included in the delivery handoff. A value of Y indicates that the property class should
be included.

Field DEL.INFO.REQ in AA.PROPERTY.CLASS.

Currently this field is delivered pre-configured by Temenos and cannot be amended.

Creating Message Types for AA

New messages (or existing messages can be amended) can be created for the arrangement activity
application. The message type is defined in the application DE.MESSAGE and has a numeric
message number between 1 and 9999.
When the message is created the data elements that the message is to be comprised of should be
defined. For further details of DE.MESSAGE application please refer to the Delivery User Guide.

Creating Mapping Definitions for the AA Application

Having defined the message the next step is to define the mapping between the handoff data and the
message content. This is defined in the DE.MAPPING table.
The key to this table is comprised of:

• Message Type (the key to DE.MESSAGE).

• Application Identifier (AA should be used in this case).
• Application sub type identifier.

TEMENOS T24 User Guide Page 48 of 183

Arrangement Architecture – Introduction / Property Classes

It is recommended that a different Application Identifier should be chosen for each product line (and
possibly different product groups under the same product line) as this will allow multiple products to
produce the same message type from different content.

For an AA mapping definition the following should be defined:

Link between named handoff records and underlying applications - In the following example we can
see that:

• INPUT.REC.7 MEMBER is the named CUSTOMER property class.

• INPUT.REC.8 COMMITMENT is the named TERM.AMOUNT property class.

TEMENOS T24 User Guide Page 49 of 183

Arrangement Architecture – Introduction / Property Classes

Example of Handoff Record Definitions.

The handoff record number that contains the name of the product properties must also be defined in
the field RECORD.NAME.LOC. For the AA module record 7 will always contain the property definition.

TEMENOS T24 User Guide Page 50 of 183

Arrangement Architecture – Introduction / Property Classes

Defining the Location of the Named Handoff Records.

The mapping between the message fields and the delivery handoff records can then be defined using
fields INPUT.POSITION, INPUT.NAME and HEADER.NAME.
Where data is to be mapped from a property the INPUT.POSITION should contain the name of the
property, and INPUT.NAME should contain the field name from the property.
Data contained in the fixed data handoff records should be mapped by specifying either:

• INPUT.POSITION as the record number with INPUT.NAME as the required field name.
• INPUT.POSITION only in the format record field.

TEMENOS T24 User Guide Page 51 of 183

Arrangement Architecture – Introduction / Property Classes

As shown in the following example.

Mapping Handoff Data to Message Fields.

TEMENOS T24 User Guide Page 52 of 183

Arrangement Architecture – Introduction / Property Classes

Linking Soft Delivery to Activities – Property Attributes and Use

Delivery events generated from AA module must contain an EB.ADVICES code. The
ACTIVITY.MESSAGING property allows either an AA.ACTIVITY, or AA.ACTIVITY.CLASS to be
linked to an EB.ADVICES code.
In order to generate a delivery event for an ADVICE code that has already been defined in
EB.ADVICES must be defined. Associated with this code must be either:

• The AA.ACTIVITY name that should trigger the production of the event or
• The AA.ACTIVITY.CLASS name that should the production of the event for any AA.ACTIVITY
of this AA.ACTIVITY.CLASS.

Example of Specific AA.ACTIVITY link in ACTIVITY MESSAGING.

Defining EB.ADVICES for the selected ADVICE

The EB.ADVICES table provides the link between the ADVICE code allocated and the message
types to be produced.
As show above the EB.ADVICE record AC-0190 will be used if triggered by either the
AA.ACTIVITY or AA.ACTIVITY.CLASS action.
The MESASGE.TYPE specified should be the message type that is to be associated with this activity
(multiple message types can be linked if required).
Then MAPPING.KEY should be the id of the DE.MAPPING record built for the product and
Message.

TEMENOS T24 User Guide Page 53 of 183

Arrangement Architecture – Introduction / Property Classes

EB ADVICES definition.

Adding Additional Content to the Handoff Data

Additional handoff data can be added to the delivery event, this is controlled by the definition in the
EB.ADVICES table for the ADVICE code. The field USER.ROUTINE allows an API to be written that
can modify/add additional data to one or more of the handoff data records.

Suppressing Delivery Advices

It is possible to suppress the Delivery message at the arrangement level. This can be done using the
field SEND.ADVICE. This field is to denote whether the message needs to be send or not.
Allowed values should be YES or NO.
The user would have to trigger the update activity of ACTIVITY.MESSAGING to amend the setup at
the arrangement level.

TEMENOS T24 User Guide Page 54 of 183

Arrangement Architecture – Introduction / Property Classes

ACTIVITY.MESSAGING field SEND.ADVICE.

Delivery Message generated for New Arrangement

TEMENOS T24 User Guide Page 55 of 183

Arrangement Architecture – Introduction / Property Classes

Delivery Message not generated for Increase term amount activity

Note: The structure of the ACTIVITY.MESSAGING property class should be modified with the new
field (SEND.ADVICE).

See the Delivery user guide for full details.

TEMENOS T24 User Guide Page 56 of 183

Arrangement Architecture – Introduction / Property Classes

Property Details
Publishing - Merging property conditions
With standard business property classes (e.g. Interest), a Defined Property defined for a ‘Child
Product’ will override a Defined Property specified for a ‘Parent Product’. When published, the
ACTIVITY MESSAGING Property Class is merged in a mutually exclusive manner.
This allows for the parent property condition to contain the master definition and only those specific
activities that are required to produce alternative messages need be defined at the child level. A
definition of ADVICE.CODE at the child level will override any definition found at the parent level when
the publishing process takes place.

Link between Arrangement Activity and Delivery

The delivery system will allocate a unique message identifier for each message that is generated as a
result of the delivery event. This is stored in the AA.ARRANGEMENT.ACTIVITY record field
DELIVERY.REF.

Delivery Reference.

Delivery Preview
Currently the AA module does not support the ability to PREVIEW the delivery output to be
generated.

TEMENOS T24 User Guide Page 57 of 183

Arrangement Architecture – Introduction / Property Classes

Periodic Attribute Classes associated with Activity Messaging

There are no periodic attributes available for use with the ACTIVITY.MESSAGING property.

Action Synopsis
The ACTIVITY.MESSAGING Property supports the following actions:
UPDATE
The UPDATE action is initiated by the product tracking service. When a product definition is modified
that includes a change to the AA.PRD.DES.ACTIVITY.MESSAGING conditions this action will be
run to ensure that arrangements of that product type are updated with the new conditions.
The action will also be initiated by the NEW-ARRANGEMENT and UPDATE-ACTIVITY.MESSAGING
activities.

SEND.MESSAGE
The SEND.MESSAGE action is initiated by all activities performed on an arrangement where the
arrangement product has an ACTIVITY.MESSAGING property.
The action processing will perform the following process:

• Determine if the current specific activity or general activity class is required to produce a delivery
event
• If a delivery event is required look up the ADVICE.CODE (record of EB.ADVICE) to be used by
rules based delivery.
• A handoff request will be generated for the specified advice code together with all related property
details for the effective date of the activity.
• The delivery reference from the delivery system is stored in the
AA.ARRANGEMENT.ACTIVITY record.

Note that the SEND.MESSAGE action will only generate a delivery event on the authorisation of a
new AA.ARRANGEMENT.ACTIVITY. At reversal no delivery event is generated.

Accounting Events
Since there are no related financial balances with this property class there are no associated
accounting events generated by properties of this class.

Limits Interaction
There is no interaction between the T24 Limits system and properties of this class.

TEMENOS T24 User Guide Page 58 of 183

Arrangement Architecture – Introduction / Property Classes

Delivery
This property controls the interaction with the T24 delivery system, details of handoff records and
required configuration are described in the previous sections.

TEMENOS T24 User Guide Page 59 of 183

Arrangement Architecture – Introduction / Property Classes

ACTIVITY.PRESENTATION
Overview
The ACTIVITY PRESENTATION Property Class is used to specify the T24 Versions (hereafter referred
to as ‘screens’) that will be used when displaying an AA.ARRANGEMENT.ACTIVITY. By
specifying screens at the Product level, the display of each arrangement activity is controlled
dynamically. Upon entering the Product and Activity, T24 will determine which properties should be
displayed and which screens should be used.

Product Lines
The ACTIVITY.PRESENTATION property is used by the following product lines:

• LENDING
• DEPOSITS
• ACCOUNTS
• INTERNET.SERVICES

Product Property Relationship

The ACTIVITY.PRESENTATION product property supports the following arrangement links to the
product:

• DATED
• TRACKING.ONLY
• MERGE

TEMENOS T24 User Guide Page 60 of 183

Arrangement Architecture – Introduction / Property Classes

ACTIVITY.PRESENTATION Property Class record.

Merging property conditions

With standard business property classes (e.g. Interest), a Defined Property defined for a ‘Child
Product’ will override a Defined Property specified for a ‘Parent Product’. When published, the
ACTIVITY.PRESENTATION Property Class is merged in a mutually exclusive manner. This allows for
each screen to be individually overridden at any level in a product family.

Defining the ACTIVITY.PRESENTATION at Product Level

Within a product, screens displayed for an Arrangement Activity can be specified at three different
levels; Property Class, Property, and Property within the context of an Activity.

• Property Class Screens

Users can specify a default Version for each PROPERTY.CLASS (e.g. INTEREST). If a more specific
Version is specified for a PROPERTY or an ACT.PROPERTY, this Version will be ignored.

• Property Screens

TEMENOS T24 User Guide Page 61 of 183

Arrangement Architecture – Introduction / Property Classes

Users can specify a Version at the PROPERTY level (e.g. Principal Interest). This will override the
default of the Property Class.

• Activity Property Screens

The lowest level of Version specification allows a user to define a version for use at the Property level
(ACT.PROPERTY) within an Activity (ACTIVITY.ID).

Periodic Attribute Classes associated with Activity Presentation

There are no periodic attribute classes for the ACTIVITY.PRESENTATION property class.

Action Synopsis
The ACTIVITY.PRESENTATION Property supports the following actions:
UPDATE
The update action is initiated manually and allows the User to change any of the
ACTIVITY.PRESENTATION attributes. This action will be initiated as part of the NEW-ARRANGEMENT
and UPDATE- ACTIVITY.PRESENTATION activities and will result in the modification of the versions
and screens rules.

Accounting Events
The ACTIVITY.PRESENTATION property does not perform any actions that generate accounting
events.

Limits Interaction
The ACTIVITY.PRESENTATION property does not perform any actions that impact on the limits system.

Delivery
The ACTIVITY.MESSAGING property class controls the T24 delivery events that are generated.

TEMENOS T24 User Guide Page 62 of 183

Arrangement Architecture – Introduction / Property Classes

CHANGE.PRODUCT
Overview
The CHANGE.PRODUCT property class defines the rules and behaviour for allowing arrangements of
one product to be changed to another.
The CHANGE.PRODUCT property can be included in a product if arrangements are allowed to be
changed to another product during its lifetime or if any arrangement is to be renewed in its lifetime.
The property class allows the definition of restricted products that change can be made to and when a
scheduled change should be applied.

Product Lines
The CHANGE.PRODUCT property is used by the following product lines:

• LENDING

Property Product Relationship

The change product property supports the following arrangement links to the product:

• DATED
• TRACKING

TEMENOS T24 User Guide Page 63 of 183

Arrangement Architecture – Introduction / Property Classes

CHANGE.PRODUCT Property Class record.

Property Attribute Description and Use

Defining renewal conditions
The property has the options of choosing when renewal can be performed on the arrangement. The
CHANGE.DATE.TYPE field can hold any of the values ‘MATURITY’, ‘PERIOD’,
‘PAYMENT.END.DATE’ or can be left blank in which case the user has to specify the date in the field
CHANGE.DATE.
When MATURITY option is chosen, the renewal will happen on the maturity date and further
recalculation of maturity date (with the base date as the renewal date) will happen based on the
option chosen in the field RECALC.MATURITY.ON in TERM.AMOUNT property condition.
For recalculation of maturity date, the term of the arrangement is considered. The activity that is
performed on the renewal date should be specified in this field. The different activities can be
LENDING-ROLLOVER-ARRANGEMENT, LENDING-RESET-ARRANGEMENT or LENDING-
CHANGE.PRODUCT-ARRANGEMENT.
When PERIOD option is chosen, the renewal will happen on the date calculated by the period given in
field CHANGE.PERIOD and even for this option maturity date can be recalculated (with the base date
as renewal date) based on the activity chosen in the field RECALC.MATURITY.ON.
When PAYMENT.END.DATE is chosen, the renewal will happen on the payment end date of the
arrangement.
If a date is user specified in the field CHANGE.DATE, then renewal will happen on the date specified
by the user. However any of the renewal activity can happen only prior to the FINAL.MAT.DATE
which is based on FINAL.TERM in TERM.AMOUNT property condition.

TEMENOS T24 User Guide Page 64 of 183

Arrangement Architecture – Introduction / Property Classes

In the field CHANGE.ACTIVITY, user can choose ROLLOVER, RESET or CHANGE.PRODUCT by

which the corresponding activity will be triggered on the renewal date.
There is a field called INITIATION.TYPE which would accept values AUTO or MANUAL and is a
mandatory field. A value of AUTO would mean, on the renewal date, the activity specified in
CHANGE.ACTIVITY field will be performed and if it is MANUAL, then a value in the field
DEFAULT.ACTIVITY becomes mandatory and the same can accept LENDING-ROLLOVER-
ARRANGEMENT only currently. In this case, till the renewal date, if the user has not renewed the
loan manually, the activity LENDING-ROLLOVER-ARRANGEMENT will be performed on the renewal
date.
Consider an example where CHANGE.ACTIVITY is RESET and the CHANGE.DATE is 29D. An
arrangement is input on 30th Nov and 29th Dec is a working day. The below are the effects field
INITIATION.TYPE with values AUTO & MANUAL:
1. When the INITIATION.TYPE is MANUAL and if DEFAULT.ACTIVITY is specified as
LENDING-ROLLOVER-ARRANGEMENT, on 29th Dec start of day itself, the activity
LENDING-ROLLOVER-ARRANGEMENT will be triggered.
2. When the INITIATION.TYPE is AUTO, on 29th Dec start of day itself, the activity LENDING-
RESET-ARRANGEMENT will be triggered which is based on the value in the field
CHANGE.ACTIVITY.

Generation of New Product Conditions in Advance

The system can process the activity to change the arrangement product a number of days in advance
of the actual change date. This can be done to allow sufficient time for communication of new
conditions to the client prior to the start of the new product.
The system will generate all the new conditions according to the PRIOR.DAYS definition associated
with the CHG.TO.PRODUCT. On the change date less the number of prior days the new product
change conditions will be generated with an effective date equal to the CHANGE.DATE (or date
calculated as arrangement start date plus CHANGE.PERIOD).

Allowed Products for Change

The property allows the list of allowed products that an arrangement may change into to be specified.
The ALLOWED.PRODUCT field will contain a list of such products and the products must belong to the
same product group as the current product.
When the product is proofed it will verify that the allowed products belong to the same
AA.PRODUCT.GROUP as the product being published, if not a proofing error is generated and
must be corrected before the product can be published.

Loan Renewal
There could be several Activities which can be run by the user or in some cases automatically
scheduled which can be used to change any of the conditions of the Arrangement and in some cases
will result in the recalculation of a Renewal Date and the Maturity Date.

TEMENOS T24 User Guide Page 65 of 183

Arrangement Architecture – Introduction / Property Classes

1) ROLLOVER – Would renew with the existing Arrangement conditions and might recalculate
Maturity date if ROLLOVER option is chosen in the field RECALC.MATURITY.ON in the
TERM.AMOUNT property condition. The product conditions will not be considered except for the
properties that track the product conditions.
Consider the below example where the term is 29D and final term is 58D. User wishes to recalculate
maturity date on every renewal.

TERM.AMOUNT conditions of an Arrangement.

The activity chosen by the user to happen on the renewal date is ROLLOVER and renewal should
happen on maturity date.

CHANGE.PRODUCT condition for Arrangement.

The renewal date will be updated in AA.ACCOUNT.DETAILS which is calculated based on

maturity date.

TEMENOS T24 User Guide Page 66 of 183

Arrangement Architecture – Introduction / Property Classes

AA.ACCOUNT.DETAILS with RENEWAL DATE.

Few of the arrangement conditions as on the new arrangement date:

INTEREST CONDITION at Arrangement level.

TEMENOS T24 User Guide Page 67 of 183

Arrangement Architecture – Introduction / Property Classes

PAYMENT SCHEDULE at Arrangement level.

On 29th Dec, ROLLOVER activity is triggered recalculating the next renewal date and the maturity
date.

ROLLOVER ACTIVITY triggered.

TEMENOS T24 User Guide Page 68 of 183

Arrangement Architecture – Introduction / Property Classes

The arrangement has renewed with current conditions & is now in the final period. The conditions of
arrangement with base date as renewal date. Also maturity date is recalculated.

INTEREST CONDITION at Arrangement.

Account details with new maturity date.

TEMENOS T24 User Guide Page 69 of 183

Arrangement Architecture – Introduction / Property Classes

PAYMENT SCHEDULE at Arrangement.

2) RESET – Would reset to product conditions based on reset set-up at product level for
different properties.
Consider the below example where the term is 29D and final term is 87D. User wishes to recalculate
maturity date during RESET.

TERM AMOUNT at Arrangement.

TEMENOS T24 User Guide Page 70 of 183

Arrangement Architecture – Introduction / Property Classes

The activity chosen by the user to happen on the renewal date is RESET and resetting should happen
on payment end date. And the INITIATION.TYPE is AUTO.

CHANGE PRODUCT at Arrangement.

The renewal date will be updated in AA.ACCOUNT.DETAILS which is calculated based on

payment end date.

AA.ACCOUNT.DETAILS with RENEWAL DATE

Interest condition as on the new arrangement date:

INTEREST PROPERTY at Arrangement.

The arrangement product’s interest condition is as below and the same has been negotiated during
new arrangement input.

TEMENOS T24 User Guide Page 71 of 183

Arrangement Architecture – Introduction / Property Classes

ARRANGEMENT PRODUCT – RSP.LOAN.

For this arrangement product the interest condition is as below:

INTEREST CONDITION at PRODUCT LEVEL.

From the above we can see that the interest rate is fixed at 10% and the property condition has
DEFAULT.ATTR.OPTION set to RESETTING which means on the renewal date (when RESET
activity is triggered), the interest rate from the product condition will be effective in the arrangement.
However, the day basis will remain as ‘B’ at arrangement level as the same has been set to NON-
RESETTING using NR.OPTIONS.
On 4th Dec, there is a change in the interest condition of the product and the fixed rate is changed to
12%.

TEMENOS T24 User Guide Page 72 of 183

Arrangement Architecture – Introduction / Property Classes

INTEREST CONDITION after CHANGE.

On 29th Dec, RESET activity is triggered recalculating the next renewal date and the maturity date.

RESET ACTIVITY triggered.

The arrangement has reset with current conditions (changed condition with rate 12%). Also, though at
product level day basis of interest is ‘A’, arrangement is retained with B basis as its set to NON-
RESETTING.

INTEREST Condition at Arrangment.

TEMENOS T24 User Guide Page 73 of 183

Arrangement Architecture – Introduction / Property Classes

Also maturity date & renewal date are recalculated. Here renewal date is based on payment end
date.

AA.ACCOUNT.DETAILS with the new MATURITY & RENEWAL DATE

PAYMENT SCHEDULE showing PAYMENT.END.DATE.

3) CHANGE.PRODUCT – Would reset to product conditions of the new product (which the
existing arrangement is changing to) based on reset set-up at product level (old product) for different
properties.
The activity chosen by the user to happen on the renewal date is CHANGE.PRODUCT and the same
happens on 15th Dec (user defined date).

TEMENOS T24 User Guide Page 74 of 183

Arrangement Architecture – Introduction / Property Classes

CHANGE.PRODUCT condition of Arrangement.

The renewal date will be updated in AA.ACCOUNT.DETAILS which is calculated based on change
date.

AA.ACCOUNT.DETAILS with RENEWAL DATE.

The arrangement product’s interest condition is as below and the same has been negotiated during
new arrangement input.

INTEREST Condition of Arrangement.

TEMENOS T24 User Guide Page 75 of 183

Arrangement Architecture – Introduction / Property Classes

The property condition has DEFAULT.ATTR.OPTION set to RESETTING which means on the
renewal date (when CHANGE.PRODUCT activity is triggered), the interest rate from the new product
condition will be effective in the arrangement. However, the day basis will remain as ‘B’ at
arrangement level as the same has been set to NON-RESETTING using NR.OPTIONS.

ARRANGEMENT showing both Products with respective EFFECTIVE DATES.

INTEREST Condition at Product level with reset option.

The product of the arrangement has changed to RSP.LOAN with interest condition being reset from
RSP.LOAN and arrangement is retained with B basis as its set to NON-RESETTING.

TEMENOS T24 User Guide Page 76 of 183

Arrangement Architecture – Introduction / Property Classes

INTEREST Condition changed at Arrangement level.

INTEREST Condition at Product level of the new product.

Effect of the field DEFAULT.ATTR.OPTION on CHANGE.CONDITION activity

When there is a change in condition scheduled for a product, the same will be applied only if the field
DEFAULT.ATTR.OPTION field has value as RESETTING. If the value is NON-RESETTING or NONE,
the new condition will not take effect for the arrangement. For example, the below product is to
change from a fixed rate contract to floating rate after 30 days from input of arrangement.

Product catalog with CHANGE.CONDITION scheduled.

TEMENOS T24 User Guide Page 77 of 183

Arrangement Architecture – Introduction / Property Classes

Periodic Attribute Classes associated with Change Product

The activities that are related to this property are:

1. LENDING-ROLLOVER-ARRANGEMENT – This activity is triggered on the calculated or user

defined renewal date when the CHANGE.ACTIVITY is set to ROLLOVER in
CHANGE.PRODUCT property condition and renews the arrangement by recalculating the
next renewal date and optionally the maturity date with the arrangement’s existing conditions
or the same can be renegotiated by the user. The same can be triggered manually too.
2. LENDING-RESET-ARRANGEMENT – This activity is triggered on the calculated or user
defined renewal date when the CHANGE.ACTIVITY is set to RESET in CHANGE.PRODUCT
property condition and resets the current conditions of the product for which
DEFAULT.ATTR.OPTION is set to RESETTING. However, conditions can be renegotiated by
the user at any point of time. This also calculates the next renewal date and optionally the
maturity date. The same can be triggered manually too.
3. LENDING-CHANGE.PRODUCT-ARRANGEMENT – This activity is triggered on the
calculated or user defined renewal date when the CHANGE.ACTIVITY is set to
CHANGE.PRODUCT in CHANGE.PRODUCT property condition and also resets the currents
conditions of the new product based on the value in DEFAULT.ATTR.OPTION in the old
product. The same can be scheduled or triggered manually.
4. LENDING-UPDATE-CHANGE.PRODUCT – This is used to change any of the attributes of
CHANGE.PRODUCT property condition of an arrangement and it’s a user initiated activity.

RENEGOTIATE activity
A new activity LENDING-RENEGOTIATE-ARRANGEMENT can be used to change the arrangement
conditions of different properties at one stretch.

Periodic Restrictions
There are no periodic restrictions available for the CHANGE.PRODUCT property class.

Action Synopsis
The CHANGE.PRODUCT Property supports the following actions:
UPDATE
The update action allows modification and creation of a new CHANGE.PRODUCT property for an
arrangement. It will be performed as part of the NEW-ARRANGEMENT and UPDATE-
CHANGE.PRODUCT activities.

Accounting Events
The CHANGE.PRODUCT property does not perform any actions that generate accounting events.

TEMENOS T24 User Guide Page 78 of 183

Arrangement Architecture – Introduction / Property Classes

Limits Interaction
The CHANGE.PRODUCT property does not perform any actions that impact the limits system.

Delivery
The ACTIVITY.MESSAGING property class controls the T24 delivery events that are generated. There
are no standard delivery conditions provided for the change product activities.

TEMENOS T24 User Guide Page 79 of 183

Arrangement Architecture – Introduction / Property Classes

CHARGE
Overview
The CHARGE Property Class is used for all charge type calculations in AA. Its primary purpose is to
calculate the amount of a charge.

Product Lines
The CHARGE Property is used by the following product lines:

• LENDING
• DEPOSITS
• ACCOUNTS

Property Product Relationship

The charge Property supports the following arrangement links to the product:

• OPT.CCY
• DATED
• MULTIPLE
• TRACKING

TEMENOS T24 User Guide Page 80 of 183

Arrangement Architecture – Introduction / Property Classes

CHARGE Property Class record.

Multiple instances of a property class

It is possible to have more than one instance of a CHARGE property class. This is defined in TYPE in
type being MULTIPLE.

TEMENOS T24 User Guide Page 81 of 183

Arrangement Architecture – Introduction / Property Classes

Currency
The CHARGE Property Class differs from other Currency Specific classes in that it includes a
CURRENCY field. This field defaults to the currency of the record and specifies in which currency the
charge is defined and which currency the charge will be applied.
Specifying the currency in a separate field allows for the following capabilities:

• Charging in a currency different from that of the Arrangement (i.e. with charges defined in a
currency which is different than the record’s currency) For example the product charges may be
defined in USD for arrangements in all currencies, but a different set of charge tariffs may be
defined for contracts in different currencies but also in USD. So a GBP contract may attract a
charge of 10 USD and a EUR contract may attract a charge of 20 USD.
• Default Currency charging – In this (optional currency) case a currency need not be specified in
the ID of the record and the user will have to set the Currency field explicitly. Any arrangement
which is in a currency for which a currency specific record has not been defined will use this
default record and calculate/apply the charge in the currency specified in the CURRENCY field.

The calculated charge should be converted to the arrangement currency at the prevailing mid-rate
(stored on the CURRENCY table) when applied.

Fixed Amount Charge

To define a fixed charge amount, the user sets the CHARGE.TYPE to “Fixed”, enters the amount of the
charge in AMOUNT.

Calculated Charge
For a Calculated charge amount, the user sets the CHARGE TYPE to “Calculated” and defines the
calculation in the following fields:

Calculation Threshold
A user can specify that a charge will only be calculated if an amount threshold is surpassed. The
threshold amount is of the same base type (i.e. activity amount, balance, activity count) as the base
type for which the charge is being calculated and is defined in CALC.THRESHOLD.

Free Amount
An amount which will be deducted from the total calculated charge subject to any minimum and
maximum which may be specified- defined in FREE.AMOUNT.

Single or Multiple Tiers

Field TIER.GROUPS allows for either a single charge calculation (select NONE) or for the definition of
multiple tiers of charge calculations (select BAND or LEVEL)
• Level - a product can be defined which will calculate a charge differently depending on the
amount level. A single charge calculation will be selected and applied based upon the amount.
An example using the following tiers:

TEMENOS T24 User Guide Page 82 of 183

Arrangement Architecture – Introduction / Property Classes

Tier Level Charge

10,000 1%
20,000 .75%
Above 20,000 .5%

A base value of 5,000 would attract a charge of 1% of 5,000 = 50.00

A base value of 15,000 would attract a charge of .75% of 15,000 = 112.50
A base value of 25,000 would attract a charge of .5% of 25,000 = 125.00

• Band - will typically result in a “blended” charge calculation. This is similar to ‘Level’ tiers, but
allows for the charge calculation of each tier to be applied to the portion of the amount that falls
within the tier.
An example using same tiers as above:

Tier Level Charge

10,000 1%
20,000 .75%
Above 20,000 .5%

A base value of 5,000 would attract a charge of 1% of 5,000 = 50.00

A base value of 15,000 would attract a charge of 1% of 10,000 = 100.00
Plus .75% of 5,000 = 37.5
Total of = 137.5
A base value of 25,000 would attract a charge of 1% of 10,000 = 100.00
Plus .75% of 10,000 = 75.00
Plus .5% of 5,000 = 25.00
Total of = 225.00

• Tier Groups (Bands and Levels) – it is possible to define complex tiers which are mixed groups of
Bands and Levels.

Any number of tier groups is possible. The User can define these groups by using a combination of
TIER.GROUP and CALC.TIER.TYPE. Each TIER.GROUP is treated as a ‘high level’ tier, if the
TIER.GROUP is level, only the detail in CALC.TIER.TYPE from the tier group in which the base value
falls will be used in the calculation. If the TIER.GROUP is band, the detail from all tier groups that
cover the base value be used in the calculation.
The value of the tiers defined in TIER.AMOUNT within each tier group should increase, only the final
tier in the final tier group should specify the remainder calculation detail.

TEMENOS T24 User Guide Page 83 of 183

Arrangement Architecture – Introduction / Property Classes

For example:
Tier Group 1
Tier Type Tier Level Charge
LEVEL 10,000 1%
LEVEL 20,000 .75%

Tier Group 2
Tier Type Tier Level Charge
BAND 30,000 .25%
BAND 40,000 .20%
BAND Above 40,000 .15%

When the TIER.GROUP structure is LEVEL:

A base value of 15,000 would result in a charge of .75% of 15,000 = 112.50
A base value of 25,000 would result in a charge of .25% of 25,000 = 62.50
A base value of 50,000 would result in a charge of .25% of 30,000 = 75.00
Plus .20% of 10,000 = 20.00
Plus .15% of 10,000 = 15.00
Total = 110.00

When the Tier Group Structure is BAND:

A base value of 15,000 would result in a charge of .75% of 15,000 = 112.50
A base value of 25,000 would result in a charge of .75% of 20,000 = 150.00
Plus .25% of 5,000 = 12.50
Total = 162.50
A base value of 50,000 would result in a charge of .75% of 20,000 = 150.00
Plus .25% of 10,000 = 25.00
Plus .20% of 10,000 = 20.00
Plus .15% of 10,000 = 15.00
Total = 210.00

Calculation Type and Charge

For each tier defined, T24 supports three different calculation types; Flat, Percentage, or Unit and
these are defined in CALC.TYPE.

• Flat Charge – the user specifies an amount that will be charged for the tier. This type of charge is
only applicable for ‘Level’ tiers.

TEMENOS T24 User Guide Page 84 of 183

Arrangement Architecture – Introduction / Property Classes

• Percentage Charge – a percentage of the base value will be calculated.

• Unit Charge – the base value is multiplied by the number of units.
The charge amount entered is expressed either as a flat amount, a percentage, or an amount per unit.

Minimums and Maximums

Charge minimums and maximums can be specified in two ways:

• Tier Level – the user can specify a minimum and/or maximum charge amount for each tier
defined. These rates are defined in TIER.MIN.CHARGE and TIER.MAX.CHARGE.
• Overall – the user can specify overall minimum and/or maximum charges through the user of two
Periodic Attributes.
•
See Product Builder User Guide for details on Periodic Attributes.

Balance Calculation Basis

For charges which are based upon balance amounts, the user must define the calculation basis in
AA.BALANCE.CALC.TYPE which specifies how the balance amount is determined.

AA.BALANCE.CALC.TYPE.

In AA.BALANCE.CALC.TYPE, the User defines whether the balance is based on a debit or credit
balance in DEBIT.CREDIT. A dropdown list in CALCULATION gives options of DAILY, AVERAGE,
HIGHEST, LOWEST or ROUTINE. The User can define the calculation start and end dates in
CALC.START.DATE and CALC.END.DATE respectively. If ROUTINE is selected in
CALCULATION.TYPE, the routine must also be entered into ROUTINE.

TEMENOS T24 User Guide Page 85 of 183

Arrangement Architecture – Introduction / Property Classes

Each record is linked to just one PROPERTY.CLASS and once this is defined, it becomes a no change
field.

AA.BALANCE.CALC.TYPE.

Activity Calculation Basis

For charges which are based upon specific activities, the user must define the calculation basis in
AA.ACTIVITY.CALC.TYPE

Rounding of Calculations
T24 will by default round an amount according to the setting of its currency. If the user requires a
different method of rounding that is charge specific they may enter an appropriate rounding rule into
EB.ROUNDING.RULE to override the currency specified method.

Charge Routine
Certain types of charging are more complex than the options available. In such a case, a user-
defined routine can be specified to determine the charge amount.

Suspension with Capitalisation

It is possible to allow arrangement to be suspended even if interest is being capitalised.

TEMENOS T24 User Guide Page 86 of 183

Arrangement Architecture – Introduction / Property Classes

CHARGE Property type is SUSPEND.

CHARGE Property set to CAPITALISE at product condition.

Periodic Attribute Classes associated with Charge

The CHARGE Property Class provides the following Periodic Attribute Classes from which users may
define Periodic Attributes.

• MAXIMUM.CHARGE
• MINIMUM.CHARGE

TEMENOS T24 User Guide Page 87 of 183

Arrangement Architecture – Introduction / Property Classes

Action Synopsis
The CHARGE Property supports the following actions:
CHANGE
The change activity is initiated manually by the user in order to change any of the CHARGE attributes.
As a result a recalculation of the Payment Schedule may be performed.

Other actions are ACT.CAPITALISE, ACT.MAKE.DUE, CHANGE, CALCULATE, ISSUE.BILL,

MAKE.DUE, CAPITALISE, REPAY, RESUME, SUSPEND, UPDATE, CAPTURE.BILL, ADJUST.BILL
and AGE.BILLS.

Accounting Events
The following actions generate accounting events as defined in field ACCOUNTING.
• ACT.CAPITALISE
• ACT.MAKE.DUE
• MAKE.DUE
• CAPITALISE
• REPAY
• RESUME
• SUSPEND
• CAPTURE.BILL
• ADJUST.BILL
• AGE.BILLS

Limits Interaction
The CHARGE property does not perform any actions that impact the limits system.

Delivery
The ACTIVITY.MESSAGING property class controls the T24 delivery events that are generated. There
are no standard delivery conditions provided for the change product activities.

TEMENOS T24 User Guide Page 88 of 183

Arrangement Architecture – Introduction / Property Classes

CUSTOMER
Overview
The CUSTOMER Property Class is used by all products to specify all of the involved parties of an
arrangement and their respective roles.

Product Lines
The CUSTOMER property is used by the following product lines:

• LENDING
• DEPOSITS
• ACCOUNTS
• INTERNET.SERVICES

Property Product Relationship

The CUSTOMER product property supports the following arrangement links to the product:

• DATED
• NON.TRACKING

TEMENOS T24 User Guide Page 89 of 183

Arrangement Architecture – Introduction / Property Classes

CUSTOMER Property Class record.

Defining the CUSTOMER at Arrangement Level

The Customer will always be defined at Arrangement level.
Each arrangement can have one or more legal owners defined in OWNER. Additionally, other parties
may be added to an arrangement with a designated role – these will be added in the multi value set of
fields OTHER.PARTY and ROLE.
A third field within this multi value set is NOTES which enables the user to add any notes relating to
the other party. All owners and any other parties must exist on the T24 CUSTOMER file. The options
for field ROLE are specified by the user in the virtual table AA.PARTY.ROLE using EB.LOOKUP.

EB.LOOKUP – Party Roles

TEMENOS T24 User Guide Page 90 of 183

Arrangement Architecture – Introduction / Property Classes

If more than one owner is specified on an arrangement, the user must select the primary owner in
field PRIMARY.OWNER. The primary owner is used by T24 for balance sheet accounting and tax
purposes.

Periodic Attribute Classes associated with Customer

There are no periodic attribute classes for the CUSTOMER property class.

Actions Synopsis
The CUSTOMER Property supports the following actions:
UPDATE
The update action is initiated manually and allows the User to change any of the CUSTOMER
attributes. This action will be initiated as part of the NEW-ARRANGEMENT and UPDATE- CUSTOMER
activities and any modification to the static customer data will result in changes to related data within
other applications (Eg ACCOUNT).
The PRIMARY.OWNER field cannot be changed once the Arrangement has been created.

Accounting Events
The CUSTOMER property does not perform any actions that generate accounting events.

Limits Interaction
The CUSTOMER property does not perform any actions that impact on the limits system.

Delivery
The ACTIVITY.MESSAGING property class controls the T24 delivery events that are generated. The
CUSTOMER property class generates delivery information as defined in field DEL.INFO.REQD.

TEMENOS T24 User Guide Page 91 of 183

Arrangement Architecture – Introduction / Property Classes

INTEREST
Overview
The INTEREST Property Class is used for all interest definition and processing in AA. A T24 product
defined and processed in AA can have multiple interest properties defined (e.g. principal interest,
penalty interest, commission, etc.). The number of interest properties is determined by the users
defining the products.

Product Lines
The INTEREST property is used by the following product lines:

• LENDING
• DEPOSITS
• ACCOUNTS

Property Product Relationship

The INTEREST product property supports the following arrangement links to the product:

• DATED
• CCY
• MULTIPLE
• TRACKING

TEMENOS T24 User Guide Page 92 of 183

Arrangement Architecture – Introduction / Property Classes

INTEREST Property Class record.

Multiple instances of a property class

It is possible to have more than one instance of an INTEREST property class. This could comprise of
examples such as Loan Interest, Penalty Interest or Overdue Interest.
This is defined in the field TYPE with a value of MULTIPLE as shown above

Defining the INTEREST at Product Level

Most INTEREST conditions will be set at Product level, but there will be the option to negotiate all of
some of the fields within the INTEREST property at Arrangement level if this is required.

Three basic types of interest are supported by T24 Fixed, Floating, and Periodic. Each of these
interest types can include one or more margins and can be specified in a tiered structure

TEMENOS T24 User Guide Page 93 of 183

Arrangement Architecture – Introduction / Property Classes

Fixed Rate Interest

Fixed Rate - A fixed rate is directly entered by the user into field FIXED.RATE. This rate must be
entered as positive numbers unless a negative rate is allowed.

Floating Rate Interest

Floating Rate- A floating interest rate is tied to a variable base rate (i.e. BASIC.INTEREST) and is
entered in field FLOATING.INDEX. During interest calculations, T24 will use the currency specific rate
applicable for the calculation date (i.e. the rate used for the calculation will change whenever the base
rate is changed).

Periodic Rate Interest

Periodic Rate - A periodic rate is tied to an index (e.g. LIBOR) which is dependent on a period of time
(e.g. term) and possibly an amount. The periodic interest index is entered into field PERIODIC.INDEX.
Once the arrangement is active, the rate is fixed until it is reset. Periodic rates can be reset at a pre-
determined frequency. To define a periodic rate, the user specifies:

• PERIODIC.INDEX -This would be input as the 2 digit number at the beginning of the
PERIODIC.INTEREST Id, eg 01 may indicate that the LIBOR rate should be used.
• PERIODIC.PERIOD (this will default to TERM if a Term Amount Property exists).
• PERIODIC.METHOD -Interest selection method if the term is not found on the index. The options
are:
o Interpolate Rate
• PERIODIC.RESET – A Reset period can be selected using the pop up box at the end of the field.

Negative Interest Rates

It is possible to set negative interest rates on accounts in credit. This is achieved by setting the
NEGATIVE.RATE field to YES.
If this field is set as either NO or left unpopulated, then when interest rates fall below 0, zero interest
will be accrued. Negative interest rates may occur either as a result of a negative rate being specified
or as the result of the rate minus any margin which is specified.

Margins
A margin rate can be used to adjust the specified rate of interest and to appropriately reflect any rate
profit realized. The result is the nominal rate of interest which is stored in field EFFECTIVE.RATE.
T24 allows for the following margin configuration:
Single or Multiple Margins – the fields for margin are a multi value set for multiple margin types. The
types available are defined in the virtual table AA.MARGIN.TYPE in EB.LOOKUP.
Examples may be a Corporate or Treasury margin.

TEMENOS T24 User Guide Page 94 of 183

Arrangement Architecture – Introduction / Property Classes

EB.LOOKUP table.

Rate Adjustment Method – this is defined in field MARGIN.OPER with the following options:

• Add to rate.
• Subtract from rate.
• Multiply (i.e. the nominal rate is [100+Margin]% of the specified interest rate).

The actual margin is defined in MARGIN.RATE.

COMPOUND interest
T24 supports the compounding of both debit and credit interest in field COMPOUND.TYPE. The
following compound frequencies are supported:

• Daily (D) – Interest is compounded 365/6 times a year.

• Annual (M12) – Interest is compounded once per year.
• Semi-Annual (M06) – Interest is compounded 2 times a year.
• Quarterly (M03) – Interest is compounded 4 times a year.
• Monthly (M01) – Interest is compounded 12 times a year.
• Bi-Monthly (M02) – Interest is compounded 6 times a year.
• Twice-Monthly (TWMTH) – Interest is compounded 24 times a year.
• Weekly (WEEK) – Interest is compounded 52 times a year.
• Bi-Weekly (WEEK2) – Interest is compounded 26 times a year.

Types of Interest Rate

T24 allows for the definition of different types of interest rates.
There are three types of tiers; BAND, LEVEL and SINGLE and these are selected in field
RATE.TIER.TYPE.

SINGLE
If the option SINGLE is selected, a single nominal interest rate will apply for the entire balance
amount.

TEMENOS T24 User Guide Page 95 of 183

Arrangement Architecture – Introduction / Property Classes

LEVEL
By specifying level tiers a product can be defined which will calculate interest at different rates
depending on the balance amount. A single rate of interest will be selected and applied based upon
the balance amount.
For a deposit you might want to have a higher rate of interest for accounts which maintain higher
credit balances. Conversely, for a loan product, a higher rate of interest can be charged for accounts
with higher debit balances.
For example, assuming a credit balance of 15,000 and level interest which specifies an applicable
rate of 10 per cent up to 10,000 and 15 per cent above 10,000. A single rate of 15 per cent will be
applied to the entire amount of 15,000.
BAND
Banded tier interest will typically result in a “blended” interest rate. This is similar to Level tiers, but
allows for the interest rate of each tier to be applied to the portion of the balance that falls within the
tier.
For example, assuming a credit balance of 15,000 and banded interest which specifies an applicable
rate of 10 per cent up to 10,000 and 15 per cent above 10,000. Two calculations will be performed (i.e.
10 per cent on 10,000 and 15 per cent on 5,000).

Each tier is specified by defining the amount up to which the interest rate applies. Additionally, each
tier can be of a different interest rate type (i.e. fixed, floating, or periodic).
In each case the fields FIXED.RATE through to TIER.AMOUNT are part of a multi value set of fields
and can be utilised if either LEVEL or BAND are selected. The rate to be applied to the calculation
amount is specified in the field TIER.AMOUNT.

It is possible to control the interest rate of an account during its lifetime using TIER.MIN.RATE and
TIER.MAX.RATE. This is applicable for variable and periodic rates and allows the tier rate to be
controlled.

Interest Calculation Basis

The calculation basis determines on what balance amount interest is to be calculated and is input in
field BALANCE.CALC.TYPE. The Interest Property Class provides for user defined balance calculation
types.
The following configuration can be defined by the user through AA.BALANCE.CALC.TYPE:

• Debit or Credit Balance.

• Calculation Type (Average, Current, Daily, Highest, Lowest, Routine).
• Calculation Start and End days. This allows the specification of a calculation period within the
capitalisation period and applies to Highest or Lowest calculation types.
• Calculation Routine which allows for a user-defined program to determine the balance amount.

TEMENOS T24 User Guide Page 96 of 183

Arrangement Architecture – Introduction / Property Classes

Interest Calculation Threshold

Using field CALCULATION.THRESHOLD, a user can specify that interest will only be calculated if a
balance threshold is surpassed. For credit interest, the user can specify the minimum balance which
must be maintained. For debit interest, the user can specify the maximum debit balance for which
interest will not be calculated.

Interest Accrual Rules

When accruing interest, T24 must determine which amounts to include in each day’s balance, the
actual days to include in the period (e.g. first day, last day) and how to round any calculations. T24
allows users to define the calculation method to use, by specifying an accrual rule in
EB.ACCRUAL.PARAM.
Users can define the following in field ACCRUAL.RULE.
• First Day Inclusive (Yes/No)
• Last Day Inclusive (Yes/No)
• Rounding Rule (Natural, Down, Up, Currency, None)
• Intermediate Calculation Rounding (Yes/No)
• Credit value date adjustment
• Debit value date adjustment

Interest Day Basis

T24 can calculate interest based on day basis types which are defined in the application
INTEREST.BASIS and these values are stored in the field DAY.BASIS.
Each Interest Day Basis type is represented as a numerator and denominator.
• Numerator (interest days)
o 360 – Each month is considered to have 30 days
o 366 – The exact number of days will be used
• Denominator (days in the year)
o 360 – Each year is considered to have 360 days
o 365 – Each year is considered to have 365 days
o 366 – The exact number of days in the year will be used (365 or 366)

T24 allows the following interest day basis types:-

TEMENOS T24 User Guide Page 97 of 183

Arrangement Architecture – Introduction / Property Classes

INTEREST.BASIS table.

Rate Control
T24 provides several ways to control the interest rate of an account during its lifetime.
• Tier Minimum/Maximum - For each tier defined, a user can specify a TIER.MIN.RATE and/or
TIER.MAX.RATE for the tier. This is applicable for variable and periodic rates and allows the tier
rate to be controlled.
• Rate Increase and Rate Decrease - Through periodic rules, users can control the increase and
decrease of the overall rate during a period of time (e.g. per month, per year, account lifetime,
etc).
• Rate Cap and Rate Floor - Through periodic rules, users can control the maximum (cap) and
minimum (floor) rates that apply to a balance amount.

Suspension with Capitalisation

It is possible to allow arrangement to be suspended even if interest is being capitalised.

TEMENOS T24 User Guide Page 98 of 183

Arrangement Architecture – Introduction / Property Classes

INTEREST Property type is SUSPEND.

INTEREST Property set to CAPITALISE at product condition.

Consider an example where USD 1000.00 is already suspended. Now, on schedule date, as interest
is set to capitalise, this USD 1000.00 will be reversed from the suspension category and booked
under P&L and the entries for capitalisation will be - credit the accrual category if interest property and
debit the current balance of Account property.

TEMENOS T24 User Guide Page 99 of 183

Arrangement Architecture – Introduction / Property Classes

Periodic Attribute Classes associated with Interest

The INTEREST property class provides the following periodic attribute class from which users may
define periodic attributes

• MAXIMUM.RATE
• MINIMUM.RATE
• RATE.INCREASE
• RATE.DECRESE
• RATE.DECREASE.TOLERANCE
• RATE.INCREASE.TOLERANCE

Action Synopsis
The INTEREST Property supports the following actions:
ACCRUE
The accrue action can be initiated by the system or manually as part of the ACCRUE-INTEREST
activity. This will result in calculation of the accrued interest amount to the requested effective date
and the generation of accounting entries.

CAPITALISE
The action capitalise can be initiated by the system. This will result in calculation of the accrued
interest amount to the requested effective date and the generation of accounting entries.

MAKE.DUE
The make due action will apply the amount of interest due to be repaid to the DUE interest property.
The amount to be made due is determined from the associated BILL that is being made due.

REPAY
The repay action will allocate the amount of interest to be repaid to the appropriate account balance.
Depending on the PAYMENT.RULE applied the interest will be made against billed or current
amounts.

UPDATE
The UPDATE action is initiated manually and allows the User to change any of the INTEREST
attributes. This action will be initiated as part of the NEW-ARRANGEMENT and UPDATE- INTEREST
activities.

TEMENOS T24 User Guide Page 100 of 183

Arrangement Architecture – Introduction / Property Classes

DEBIT
The debit action applies the unallocated amount from a debit to the arrangement to the unallocated
debit balance of the arrangement.

CREDIT
The credit action applies the unallocated amount from a credit to the arrangement to the unallocated
credit balance of the arrangement

Other ACTIONS are PERIODIC.RESET, SUSPEND, ADJUST and RESUME.

Accounting Events
The following actions generate accounting events as defined in field ACCOUNTING.
• ACCRUE
• CAPITALISE
• MAKE.DUE
• REPAY
• SUSPEND
• RESUME
• DEBIT
• CREDIT
• CAPTURE.BILL
• ADJUST.BILL
• AGE.BILLA

Limits Interaction
The INTEREST property does not perform any actions that impact on the limits system.

Delivery
The ACTIVITY.MESSAGING property class controls the T24 delivery events that are generated.
The INTEREST property class generates delivery information as defined in field DEL.INFO.REQD.

TEMENOS T24 User Guide Page 101 of 183

Arrangement Architecture – Introduction / Property Classes

INTEREST with DEL.INFO.REQD defined.

TEMENOS T24 User Guide Page 102 of 183

Arrangement Architecture – Introduction / Property Classes

LIMIT
Overview
The LIMIT Property Class is used by all products which are account based. This property class
primarily controls the use of the LIMIT module by the account.

Product Lines
The LIMIT property is used by the following product lines:

• LENDING
• DEPOSITS
• ACCOUNTS

Property product Relationship

The LIMIT product property supports the following arrangement links to the product:

• DATED
• NON.TRACKING

TEMENOS T24 User Guide Page 103 of 183

Arrangement Architecture – Introduction / Property Classes

LIMIT Property Class.

Defining LIMIT conditions at Product Level

The conditions for the LIMIT will usually be defined at Product level and rarely changed or negotiated
at Arrangement level.
If the primary owner of the arrangement has a credit limit covering this account, the reference to that
Limit is specified in field LIMIT.REFERENCE. (For the LENDING Product Line the Limit Reference is
mandatory). If no limit reference is specified, and the ‘working balance’ will go into debit, an
'Unauthorized Overdraft' message is displayed and an override is required before the transaction will
be accepted. If a reference is specified, the corresponding Limit record is checked. If it covers the new
‘working balance’, the transaction is accepted; otherwise an override is required before the
transaction will be accepted.

Single Limit
An account can require exclusive use of a Limit. This can be defined at the Product level in field
SINGLE.LIMIT and negotiated at the Arrangement level if necessary.

Netting the Limit

If an account does not exclusively use a Limit, the user can specify that any credit balance of the
account can be added to the overall overdraft limit available to other accounts with the same limit
reference. This is specified in field ALLOW.NETTING where the options are YES or NO.

TEMENOS T24 User Guide Page 104 of 183

Arrangement Architecture – Introduction / Property Classes

Periodic Attribute Classes associated with Limit

There are no periodic attributes available for use with the LIMIT property

Action Synopsis
The LIMIT Property supports the following actions:
UPDATE
The update action is initiated manually and allows the User to change any of the LIMIT attributes. This
action will be initiated as part of the NEW-ARRANGEMENT and UPDATE- LIMIT activities.

CHANGE

Accounting Events
The LIMIT Property does not perform any actions that generate accounting events.

Delivery
The ACTIVITY.MESSAGING Property class controls the T24 delivery events that are generated. The
LIMIT property class generates delivery information as defined in field DEL.INFO.REQD.

Field DEL.INFO.REQD.

TEMENOS T24 User Guide Page 105 of 183

Arrangement Architecture – Introduction / Property Classes

OFFICERS
Overview
The OFFICERS Property Class is used by all products which need to assign product/arrangement
specific officers (i.e. different from the customer’s default officer

Product Lines
The OFFICERS property is used by the following product lines:

• LENDING
• DEPOSITS
• ACCOUNTS

Property product Relationship

The OFFICERS product property supports the following arrangement links to the product:

• DATED
• TRACKING

TEMENOS T24 User Guide Page 106 of 183

Arrangement Architecture – Introduction / Property Classes

OFFICERS Property Class record.

Defining OFFICERS conditions at Product Level

The conditions for the OFFICERS will usually be defined at Product level and rarely changed or
negotiated at Arrangement level.
Both a primary and other officer can be specified in fields PRIMARY.OFFICER and OTHER.OFFICER.
If a second officer is defined, the role must also be defined in OFFICER.ROLE and any notes can be
added also. The officer roles are defined in the virtual table AA.OFFICER.ROLE in EB.LOOKUP.

TEMENOS T24 User Guide Page 107 of 183

Arrangement Architecture – Introduction / Property Classes

EB.LOOKUP table.

Action Synopsis
The OFFICERS Property supports the following actions:
UPDATE
The update action is initiated manually and allows the User to change any of the OFFICERS attributes.
This action will be initiated as part of the NEW-ARRANGEMENT and UPDATE- OFFICERS activities.

Accounting Events
The OFFICERS Property does not perform any actions that generate accounting events.

Limits Interaction
The OFFICERS Property does not perform any actions that impact on the limits system.

Delivery
The ACTIVITY.MESSAGING property class controls the T24 delivery events that are generated. The
OFFICERS property class generates delivery information as defined in field DEL.INFO.REQD.

TEMENOS T24 User Guide Page 108 of 183

Arrangement Architecture – Introduction / Property Classes

OVERDUE
Overview
The OVERDUE Property Class is used by products which require past due processing. The financial
institution can create and manage its own overdue statuses (e.g. grace, overdue, non-accrual, etc.)
and can have different status for different products.

Product Lines
The OVERDUE property is used by the following product lines:

• LENDING
• ACCOUNTS

Property Product Relationship

The OVERDUE product property supports the following arrangement links to the product:

• DATED
• TRACKING – The definition below means that the OVERDUE property can be TRACKING, but the
other options are also possible.

TEMENOS T24 User Guide Page 109 of 183

Arrangement Architecture – Introduction / Property Classes

OVERDUE Property Class record.

Defining OVERDUE conditions at Product Level

The conditions for the OVERDUE Property will usually be defined at Product level.
The Overdue Property Class is primarily a list of Status Rules and Payment Tolerance conditions.

Status Rule
Each Status Rule defines when ageing of a bill will occur and the conditions to apply for the ageing
activity. The status rules are defined in sequential order.

TEMENOS T24 User Guide Page 110 of 183

Arrangement Architecture – Introduction / Property Classes

Each OVERDUE.STATUS that overdue amounts can age through is specified by the user in
EB.LOOKUP.

EB.LOOKUP for AA.OVERDUE.STATUS.

Each Overdue Status can then be used to specify the ageing conditions and any associated
accounting. Within the specified AC.ALLOCATION.RULE, the event corresponds to the Status.

Aging
The ageing process can take place depending on the number of days after the bill was due or by the
number of overdue bills. This selection is made in field AGEING.TYPE.
The number of days or bills (relative to the amount due date) before an amount attains this Overdue
Status is specified in AGEING.

Notices
For each Overdue Status defined, a notice may be sent to the customer informing them of the status
of their arrangement. The user can specify a number of days after the status start to send a notice in
NOTICE.DAYS or notices can be sent out periodically until an arrangement is no longer in this
Overdue Status by adding a frequency in NOTICE.FREQ.

Age all Bills

A user can specify that if a bill reaches a certain status, all other bills for the arrangement will be aged
to the same status. Select AGE.ALL.BILLS for the required status. This functionality is typically used
for a “non-accrual” status which will result in all bills becoming “non-accrual” when a single bill
reaches this status.

Suspend Contract
The User can also specify that a move to this status should trigger a suspending of the arrangement.
Choosing field SUSPEND with a value of YES would result in the suspension of P&L entries from the
date of suspension and the posting of accruals to a special CRF category.

TEMENOS T24 User Guide Page 111 of 183

Arrangement Architecture – Introduction / Property Classes

Movement of Balances
When a bill is to be aged, the user can determine whether or not the balances associated with the bill
amounts should be moved to new balances corresponding to the status. The User can do this by
selecting YES in MOVE.BALANCES.
The associated balance for the status can be used as the basis for calculation of an interest class of
property (example Penalty Interest).
If a user has chosen to move balances upon ageing of a bill the accounting entries can have effective
dates corresponding to the Status change, the Previous Status change, or the Due date. This allows
for the ability to have a grace period and a following status which can be effective from the original
due date. This selection is in field EFFECTIVE.DATE.

Payment Tolerance
A payment tolerance is an amount or percentage of the billed amount which can remain “due” without
becoming Overdue.
For example a financial institution may decide that if a customer’s payment is within $25 of the billed
amount, overdue processing will not occur.
Example
A financial institution may decide that if a customer's payment is such that the outstanding amount
after payment is well within the tolerance defined, the bill will not be aged. For example, consider a bill
that is issued for $100 and tolerance is defined as 80%. Now, 80% of $100 is $80. Customer pays
$50. Now the bill outstanding is $70 which is well below $80 which is the tolerance calculated. Hence
the bill will not be aged.
The tolerance can be expressed as a percentage (PAY.TOLERANCE) or alternatively as amounts by
currency (TOL.CCY and TOL.AMOUNT). If the repayment of a bill is within the specified tolerance the
user can specify in field TOL.ACTION that the bill is considered to be Repaid which will result in
accounting to move the remaining balance. Alternatively the user can specify that the bill will Remain
in the current status but will not be aged.

Delinquency Processing
It is possible to allow actual settlement of repayment amount towards overdue bills which will still be
based on the settlement sequence defined in PAYMENT.RULES property class – which is by Property
or by bill date and Property within the bill.
The bill may be deemed as settled from delinquency stand point but may contain outstanding dues at
the end of the settlement allocation.
This can be specified using the fields BILL.SETTLEMENT with a value of BILL.TOTAL and
AGE.BILLS set to BILL.STATUS.

TEMENOS T24 User Guide Page 112 of 183

Arrangement Architecture – Introduction / Property Classes

AA.PRD.DES.OVERDUE with fields set.

The field DELIN.OS.AMT in AA.BILL.DETAILS holds the outstanding Delinquency amount

pertaining to that bill.

AA.BILL.DETAILS with DELIN.OS.AMT set.

TEMENOS T24 User Guide Page 113 of 183

Arrangement Architecture – Introduction / Property Classes

After make due, DELIN.OS.AMT is equal to the OS.TOTAL.AMOUNT, while repayment, if the
repayment amount is equal to the BILL.AMOUNT then the DELIN.OS.AMT field is marked as 0 and
the bill is marked as settled and the bill is not considered for ageing.
If the OS.TOTAL.AMT still exists for the bill, when further repayments are made the OS.TOTAL.AMT
in the bill is settled first.
The overdue status is also updated in Account record.

ACCOUNT record with OVERDUE.STATUS updated.

The delinquent bill is settled and the field AGING.STATUS is marked as SETTLED in the
AA.ACCOUNT.DETAILS record.

AA.ACCOUNT.DETAILS with AGING.STATUS set.

TEMENOS T24 User Guide Page 114 of 183

Arrangement Architecture – Introduction / Property Classes

Consider the case where 2 bills are made due to an extent of 100 each. A repayment is made to an
extent of 100 where the repayment sequence is by BILL.PROPERTY (Seq: Account, Interest), as per
delinquency setting the 100 should settle the 1st bill and make the field DELIN.OS.AMT as 0.
The below table describes the delinquency processing before and after repayments.

Balances Before repayment

Total Property details
Bill
Orig. OS Property Orig. OS
Principal 80 80
Bill 1 100 100
Interest 20 20
Principal 80 80
Bill 2 100 100
Interest 20 20

Balances after repayment (Repayment by Bill property (Account, Interest))

Total Property details
Bill
Orig. OS Dl OS Property Orig. OS
Principal 80 0
Bill 1 100 20 0
Interest 20 20
Principal 80 60
Bill 2 100 80 80
Interest 20 20

In the BALANCE.MAINTENANCE Property class, the field DELIN.OS.AMT field is captured during the
BILL.CAPTURE activity for the arrangement.

Periodic Attribute Classes associated with Overdue

There are no periodic attributes available for use with the OVERDUE property

Action Synopsis
The OVERDUE Property supports the following actions:
UPDATE
The update action is initiated manually and allows the User to change any of the OVERDUE attributes.
This action will be initiated as part of the NEW-ARRANGEMENT and UPDATE- OVERDUE activities.
Should an outstanding bill be subject to ageing the activity will first determine if the outstanding
amount of the bill is within any payment tolerance that has been specified.

TEMENOS T24 User Guide Page 115 of 183

Arrangement Architecture – Introduction / Property Classes

If a bill is to be aged, the status of the bill will be updated, the specified accounting rule will be applied
(subject to the balance movement attributes) and any applicable charging will be initiated.
If based upon satisfaction of any payment tolerance the bill is not aged its status will either remain as
is or be changed to Repaid and accounting will be triggered.

Other actions are AGE.NEW.BILL, AGE.BILLS, AGE.SCHEDULE, ISSUE.CHASER and SUSPEND.

AGE.BILLS
The Age activity will be triggered during the Close of Business based upon the due dates of
outstanding bills and the ageing attributes that have been defined for each status rule.

Accounting Events
No account events are generated from the Overdue Property Class. During the Aging process the
movement of accounting entries are handled by the respective Property actions.

Limits Interaction
The OVERDUE property does not perform any actions that impact on the limits system.

Delivery
The ACTIVITY.MESSAGING property class controls the T24 delivery events that are generated.

TEMENOS T24 User Guide Page 116 of 183

Arrangement Architecture – Introduction / Property Classes

PAYMENT.RULES
Overview
The PAYMENT RULES Property Class is used by any products which have amounts billed and made
due from the customer.
An arrangement may have several bills outstanding and each bill may be comprised of multiple
amounts (e.g. principal, principal interest, penalty, tax, charges, etc.). When a customer makes a
payment, the entire due amount may not be satisfied. The PAYMENT RULES Property Class is used to
define the method by which a single payment will be applied to multiple bills and multiple amount
types.

Product Lines
The PAYMENT.RULES Property is used by the following product lines:

• LENDING
• ACCOUNT

Property Product Relationship

The PAYMENT.RULES product property supports the following arrangement links to the product:

• DATED
• MULTIPLE
• TRACKING

TEMENOS T24 User Guide Page 117 of 183

Arrangement Architecture – Introduction / Property Classes

PAYMENT.RULES Property Class record.

Multiple instances of a property class

It is possible to have more than one instance of a PAYMENT.RULES property class. This is defined as
in field TYPE as MULTIPLE as shown above.

TEMENOS T24 User Guide Page 118 of 183

Arrangement Architecture – Introduction / Property Classes

Payment Hierarchy
T24 can apply a payment to all amounts by Property (e.g. all Principal amounts followed by all Interest
amounts, etc.) or to all amounts of by ‘Bill’ (e.g., all amount on bill 1 followed by all amounts of bill 2,
etc.). This choice is selected by the User in field APPLICATION.TYPE.
In addition to specifying whether Properties or Bills will be given priority, the user must decide in
which order multiple bills will be processed in field APPLICATION.ORDER. T24 allows a user to
specify ‘Oldest First’ (i.e. chronological) or ‘Oldest Last’.
Whether processing by Property or by ‘Bill’ the user must specify the SEQUENCE in which the Property
due amounts (i.e. types) will be paid.
If payments are to be applied by Property this specifies the sequence in which each Property’s due
amounts must be completely satisfied.
If payments are to be applied by ‘Bill’ this specifies the order on each bill of the amount Properties.
In the case where a payment activity is initiated, but there are no outstanding bills the user must
specify another activity to process. This essentially allows for the activity to be switched from a
‘repayment’ to another credit type activity.

The field PROP.APPL.TYPE represents the balance to be paid for the defined property. The values
allowed at present are CURRENT and NULL.
If this field is NULL the due balance in the bill for the property is settled according to the type defined
in the field APPLICATION.TYPE.
If the value is set to CURRENT, the current balance of the property is settled (e.g. current principal,
accrued interest, etc). This field therefore can allow settlement of current balances along with the due
balances.

Settling Current and Overdue Balances

It is possible to settle current balances with the overdue balances. This is can be specified by
specifying the value CURRENT in the field PROP.APPL.TYPE.
When set this will settle the current balance of the particular property.
If the APPLICATION.TYPE is specified as CURRENT, then PROP.APPL.TYPE field should be set to
CURRENT for all the properties.

TEMENOS T24 User Guide Page 119 of 183

Arrangement Architecture – Introduction / Property Classes

Figure 1 AA.PRD.DES.PAYMENT.RULES example.

Reminder (Overpayment)
If a payment is made which satisfies all of the due and overdue amounts and there is a remainder of
funds (i.e. an overpayment), T24 must have a pre-defined method of handling the remaining funds.
An activity to be processed for the remainder of the payment can be specified in
REMAINDER.ACTIVITY this will be subject to any Transaction Rules. Should the transaction fail, the
remainder amount will be processed by the Default Activity specified in Accounting.

Periodic Attribute Classes associated with Payment Rules

There are no periodic attributes available for use with the PAYMENT.RULES property

Action Synopsis
The PAYMENT.RULES Property supports the following actions:
UPDATE
The update action is initiated manually and allows the User to change any of the PAYMENT.RULES
attributes. This action will be initiated as part of the NEW-ARRANGEMENT and UPDATE-
PAYMENT.RULES activities.

Other actions are ALLOCATE, CREATE.DUE and PRE.BILL.

TEMENOS T24 User Guide Page 120 of 183

Arrangement Architecture – Introduction / Property Classes

Accounting Events
The PAYMENT.RULES Property does not perform any actions that generate accounting events.

Limits Interaction
The PAYMENT.RULES property does not perform any actions that impact on the limits system.

Delivery
The PAYMENT.RULES Property Class controls the T24 delivery events that are generated.
The ACTIVITY.MESSAGING property class controls the T24 delivery events that are generated as
defined in field DEL.INFO.REQD.

TEMENOS T24 User Guide Page 121 of 183

Arrangement Architecture – Introduction / Property Classes

PAYMENT.SCHEDULE
Overview
The PAYMENT SCHEDULE Property Class is used by all products which have amounts billed (i.e.
made due) or capitalised.

Product Lines
The PAYMENT.SCHEDULE property is used by the following product lines:

• LENDING
• DEPOSITS
• ACCOUNTS

Property Product Relationship

The PAYMENT.SCHEDULE product property supports the following arrangement links to the product:

• DATED
• CCY

TEMENOS T24 User Guide Page 122 of 183

Arrangement Architecture – Introduction / Property Classes

PAYMENT.SCHEDULE Property Class record.

Defining the Date Settings

The BASE DATE is an Arrangement Activity date (e.g. ‘arrangement start’, ‘first disbursement’, etc.)
which will be used during automatic payment date generation. (For arrangements which include a
TERM AMOUNT property, the base date will also be used to specify the beginning of the ‘Term’ and
the ‘Amortisation Term’).
During the automatic generation of payment schedules, the DATE.CONVENTION and
DATE.ADJUSTMENT settings indicate the action which will be taken if the derived date is a non-
working day. There are four Date Convention options:

TEMENOS T24 User Guide Page 123 of 183

Arrangement Architecture – Introduction / Property Classes

• Backward – the payment date will move backward to the last working day.
• Calendar – the payment date will not move regardless of whether it is on a working day.
• Forward – the payment date will move forward to the next working day.
• Forward Same Month – the payment date will move forward to the next working day provided it is
within the same month. If it is not within the same month, the payment date will move backward
to the last working day.

For all date conventions except for Calendar, DATE.ADJUSTMENT is used to specify whether the new
date will represent an adjustment of the ‘Value’ date of the entries or an adjust of the ‘Period’ (both
value date and processing date).
By default, T24 will check the holiday schedule for the country of an arrangement’s currency to
determine non-working days. Users can add additional countries using field BUS.DAY.CENTRES
whose calendars will also be checked with regard to holiday validation.

Amortisation and Residual Amounts

It is possible to define a RESIDUAL.AMOUNT at the maturity date of a term product that will be paid on
the last payment date of the arrangement. This can be specified by entering an
AMORTISATION.TERM with which T24 can calculate payments and any residual or by entering a
RESIDUAL.AMOUNT directly.

Defining the Payment Schedule

A Payment Schedule can be comprised of one or more Payment definitions with conditions such as
payment Type and Method, arrangement Properties, Dates and Amounts.
T24 provides a mechanism AA.PAYMENT.TYPE by which users can define the standard payment
types that can be used by a product.
A payment type is required for every payment schedule definition.

AA.PAYMENT.TYPE record.

Once the PAYMENT.TYPE has been specified, the user can specify the PAYMENT.METHOD as to
whether the amount will be Due (to or from the customer) or Capitalised. If a payment will be made
more than once, a PAYMENT.FREQUENCY must be specified.

TEMENOS T24 User Guide Page 124 of 183

Arrangement Architecture – Introduction / Property Classes

Condition record with PAYMENT.FREQ options.

This is input using the T24 frequency code. Eg 15th of each month = M0115, End of every quarter =
M0331, Weekly = WEEK1
For each Payment definition the user must specify the Properties PROPERTY with amounts to be paid
and dates for payments. If a frequency has been specified in DUE.FREQ, the user can specify a
START.DATE or it can be defaulted from the Base Date. Additionally an END.DATE or
NUM.PAYMENTS can be specified to indicate to T24 when the payments should terminate.
There can be two amounts for each payment definition; Calculated Amount and Actual Amount.
A CALC.AMOUNT is determined by T24 based upon the Payment Type and Properties involved, but it
is also possible for the user to enter an ACTUAL.AMT to override the calculated amount.

TEMENOS T24 User Guide Page 125 of 183

Arrangement Architecture – Introduction / Property Classes

Defining the Billing Rules

For each payment which is due from a customer, T24 will create a Bill record and optionally a Bill
Notice. The bill will contain the details of the amounts due, the due date, etc. This Bill record is also
the basis of the AA Overdue processing.
By default T24 will create the Bill on the due date, however for products which require a Bill notice to
be sent in advance of the due date, the user may enter the number of days prior in BILL.PRODUCED.
This will result in the due amounts being projected and recorded on the bill.
Additionally, if the bill is produced prior to the due date, the user can specify when the bill will be
considered final (i.e. the bill will not alter based upon changes to the arrangement).
T24 can also combine bills by selecting YES in BILLS.COMBINED which have the same due date
and are produced on the same date. This provides for example, the ability to combine a monthly
‘annuity’ loan repayment with a monthly charge to provide the user with a single bill amount.

Recalculate Frequency
For products which have constant payments a user may want to fix the payment amount for a period
regardless of any changes to the arrangement (e.g. principal increase, interest rate change, etc.). In
such cases a user can specify a payment RECALC.FREQUENCY so that the constant amount can be
recalculated periodically to take into consideration any of these changes.

Recalculation based on Activities

The user must specify what if anything must be recalculated should certain Activities (changes of
payment components) occur on the arrangement. These activities are input into field ON.ACTIVITY.
The following Activity Classes may require a recalculation:

• Change – Charge
• Change – Interest
• Change – Payment Schedule
• Change Term – Term Amount
• Increase – Term Amount
• Decrease – Term Amount

For each component specified on the payment schedule the resulting action must be specified in field
RECALCULATE. The recalculation types are:

• Payment – the payment amount will be changed.

• Term – the term of the arrangement will be altered.
• Residual – the residual amount will be changed.
• Nothing – the payments, term, and residual will be unchanged. In this case a recalculation
frequency should be specified.

TEMENOS T24 User Guide Page 126 of 183

Arrangement Architecture – Introduction / Property Classes

Scheduled Charges
It is possible to define that all charges be paid on a scheduled basis – i.e. on a monthly or quarterly
basis. This is scheduled in the PAYMENT.SCHEDULE property, but the User must define which
charges will apply to which activities.

Periodic Attribute Classes associated with Payment Schedule

There are no periodic attributes available for use with the PAYMENT.SCHEDULE property

Action Synopsis
The PAYMENT.SCHEDULE Property supports the following actions:
UPDATE
The update action is initiated manually and allows the User to change any of the PAYMENT.RULES
attributes. This action will be initiated as part of the NEW-ARRANGEMENT and UPDATE-
PAYMENT.RULES activities.

Other actions are CHANGE, CALCULATE, ISSUE.BILL, MAKE.DUE, CAPITALISE, SUSPEND and
SUSPEND.OVERIDE.

Accounting Events
The PAYMENT.SHEDULE Property does not perform any actions that generate accounting events.

Limits Interaction
The PAYMENT.SCHEDULE PROPERTY does not perform any actions that impact on the limits system.

Delivery
The ACTIVITY.MESSAGING property class controls the T24 delivery events that are generated. The
PAYMENT.SCHEDULE property class generates delivery information as defined in field
DEL.INFO.REQD.

TEMENOS T24 User Guide Page 127 of 183

Arrangement Architecture – Introduction / Property Classes

TERM AMOUNT
Overview
The TERM.AMOUNT Property Class is used by financial products which involve an amount of money
that is lent or deposited for a specified period of time. This property class controls the commitment
made by the bank and the customer.

Product Lines
The TERM.AMOUNT Property is used by the following product lines:

• LENDING
• DEPOSITS

Product Property Relationship

The TERM.AMOUNT product property supports the following arrangement links to the product:

• CCY
• DATED
• NON.TRACKING

For each arrangement contract the initial product default values will be stored with the arrangement
itself and cannot track the product definition.

TEMENOS T24 User Guide Page 128 of 183

Arrangement Architecture – Introduction / Property Classes

TERM.AMOUNT Property Class record.

Related Balances
The TERM.AMOUNT Property Class and linked Property has as an associated balance the current
available committed balance for the arrangement.

Current Committed Balance

For a loan contract this will reflect the available amount of the loan commitment available for disbursal.
This balance would normally be reported as a contingent balance type and will be a negative
(contingent asset) figure.

TEMENOS T24 User Guide Page 129 of 183

Arrangement Architecture – Introduction / Property Classes

The current committed principal has a prefix of CUR.

Property Attribute Description and Use

Defining the Term Amount
The user must enter the total amount which will be lent or deposited for the term (i.e. the committed
amount) into field AMOUNT. During product definition it will be common to restrict the initial amount
through negotiation rules (e.g. 5000 < amount < 25000).
In order to disburse or deposit this amount (or a portion thereof), the user will have to credit or debit
the arrangement through one of the standard T24 applications (e.g. TELLER, FUNDS.TRANSFER
etc.). These transactions may be restricted by any rules (e.g. Transaction Rules, Notice Rules, etc.)
defined in the product.
When performing the INCREASE and DECREASE activities the CHANGE.AMOUNT field is used to
record the increase or decrease in committed principal to be applied.

Defining the Term and Maturity Date of the Arrangement

The field TERM determines the period of time by which the amount must be repaid (either to the bank
in the case of a loan or to the customer in the case of a deposit). During product definition it will be
common to default the term (e.g. a 30 year mortgage).
The term can be entered in a number of ways:

• Days (calendar1) (nnnnD)

• Weeks (nnnnW)
• Months (nnnnM)
• Years (nnY)

With some products at the end of the term a customer can choose to rollover the account – this can
be performed manually or automatically using the CHANGE.PRODUCT Property.
The TERM definition is used to calculate a MATURITY.DATE for the arrangement contract, this date
can either be entered directly or will default based upon the effective date of the property and applying
the defined TERM value.
Note that a MATURITY.DATE value is currently mandatory for LENDING product lines.

TEMENOS T24 User Guide Page 130 of 183

Arrangement Architecture – Introduction / Property Classes

Example of Term and Maturity Date.

Defining whether the Arrangement is Revolving or Non-Revolving

T24 enables the definition of revolving term amounts for lending products. The effect of a revolving
product is to increase the available amount from which a customer may drawdown as a result of
certain payments. If a user wishes to have a revolving loan or line of credit there are two possible
revolving types and these are defined in field REVOLVING.

A non-revolving contract will never reinstate the available commitment amount on repayment,
whereas a revolving contract will reinstate the available amount on repayment. The following options
are available.

• NO – the available amount will not increase when any repayment of principal is made.
• PAYMENT – any payment against the outstanding principal (due or not due) will result in the
available amount increasing. Typically this setting would be used for fully revolving credit facilities.
• PREPAYMENT - only repayments against the outstanding principal (balance not yet due) – such
as an ad-hoc payment will result in the available amount increasing. Repayments against due will
not reinstate the committed amount. Typically this setting would be used when a product allows
over payment and subsequent redraw of the overpaid amount.

Updating of Limit for the Commitment

In field UPDATE.COMMT.LIMIT it is possible for the user to specify whether the commitment amount
of the LIMIT used for the arrangement is to be updated when the initial commitment is granted. A
setting of YES will result in the reduction of the limit available to the customer before any disbursal
takes place.
When disbursal takes place the LIMIT is always updated for the loan irrespective of this setting. If
this field is set to YES at disbursement time the limit will be updated to reflect that the disbursed
amount is an available amount and not committed.

TEMENOS T24 User Guide Page 131 of 183

Arrangement Architecture – Introduction / Property Classes

Periodic Attribute Classes associated with Term Amount

The TERM.AMOUNT Property Class provides the following Periodic Attribute Classes from which
users may define Periodic Attributes.
Also, on breaking the periodic rules, user can add charges that can be made due or capitalised
immediately or after a period. The same applies to all properties where periodic rules are defined.

Amount Decrease
Used to restrict the maximum amount that the committed principal can be decreased by over a
specified period of time. The rule is validated when a DECREASE activity takes place on the
TERM.AMOUNT Property.

Amounts are compared from the AMOUNT field in the TERM.AMOUNT property.
The PR.VALUE value must specify the maximum decrease AMOUNT.

AMOUNT.DECREASE record.

For example a rule could be specified that specifies a maximum decrease in principal of 1,000 is
allowed over a 6 month period.
Committed amount 6 months ago 20,000
Allowed decrease in 6 month period is 1,000
If the new AMOUNT is less than 19,000 the rule will be broken.

TEMENOS T24 User Guide Page 132 of 183

Arrangement Architecture – Introduction / Property Classes

Amount Decrease Tolerance

Similar to AMOUNT.DECREASE except that the rule specifies the percentage decrease allowed over
time rather than a specific amount. The percentage decrease is calculated as the percentage of the
value at the start of the restriction period. The rule is validated when a DECREASE activity takes
place.
The PR.VALUE value must specify the maximum decrease PERCENTAGE.

AMOUNT.DECREASE.TOLLERANCE record.

For example a rule specifies that a 5% decrease is allowed over a 6 month period.
Available balance 6 months ago 10,000
Allowed decrease in the 6 month period is 5% of 10,000 = 500
If the new AMOUNT value in the property is less than 9,500 the rule will be broken

TEMENOS T24 User Guide Page 133 of 183

Arrangement Architecture – Introduction / Property Classes

Amount Increase
Used to restrict the maximum amount that the committed principal can be increased by over a
specified period of time. The rule is validated when an INCREASE activity takes place on the
TERM.AMOUNT property.
Amounts are compared from the AMOUNT field in the TERM.AMOUNT property.
The PR.VALUE value must specify the maximum increase AMOUNT.

AMOUNT.INCREAES record.

For example a rule could be specified that specifies a maximum increase in principal of 1,000 is
allowed over a 6 month period.

Committed amount 6 months ago 20,000

Allowed decrease in 6 month period is 1,000
If the new AMOUNT is more than 21,000 the rule will be broken.

TEMENOS T24 User Guide Page 134 of 183

Arrangement Architecture – Introduction / Property Classes

Amount Increase Tolerance

Similar to AMOUNT.INCREASE except that the rule specifies the percentage increase allowed over
time rather than a specific amount. The percentage increase is calculated as the percentage of the
value at the start of the restriction period. The rule is validated when an INCREASE activity takes
place.

AMOUNT.INCREASE.TOLERANCE record.

For example a rule specifies that a 5% increase is allowed over a 6 month period.
The PR.VALUE value must specify the maximum increase PERCENTAGE.

Available balance 6 months ago 10,000

Allowed increase in the 6 month period is 5% of 10,000 = 500
If the new AMOUNT value in the property is more than 10,500 the rule will be broken.

TEMENOS T24 User Guide Page 135 of 183

Arrangement Architecture – Introduction / Property Classes

Full Disburse
Allows control of whether partial disbursement is allowed. A value of YES will specify that when the
arrangement is disbursed all committed principal for the effective date of the disbursal should be
disbursed.

FULL.DISBURSE record.

To apply this restriction for the life time of the arrangement the AA.PERIODIC.ATTRIBUTE should
be created with a DURATION.TYPE of LIFE. The field RULE.START set to AGREEMENT can be used
if the restriction only applies for duration of the current arrangement product.

The PR.VALUE value must specify YES for full disbursement to be checked.

Term Amount for Loan Renewal

The fields FINAL.TERM and FINAL.MAT.DATE along with RECALC.MATURITY.ON are used for
loan renewal. When FINAL.TERM is entered, the FINAL.MAT.DATE is calculated and defaulted in
this field and which restricts the renewal activity not to happen beyond this date. Also, the payment
amount calculation for the arrangement is based on this final term. This final term cannot be greater
than term. If both AMORTISATION.TERM (in payment schedule property) and FINAL.TERM are
input, AMORTISATION.TERM takes precedence for calculating the payment amount. However, the
renewal can happen only till final maturity date.
Whenever renewal happens, maturity date can optionally be recalculated based on the value in the
field RECALC.MATURITY.ON. This can hold values LENDING-ROLLOVER-ARRANGEMENT,
LENDING-RESET-ARRANGEMENT and/or LENDING-CHANGE.PRODUCT-ARRANGEMENT.

TEMENOS T24 User Guide Page 136 of 183

Arrangement Architecture – Introduction / Property Classes

Residual amount on maturity

The residual amount on maturity can be chosen to be made due or can remain as outstanding by
inputting DUE or NULL value in the field ON.MATURITY.

Action Synopsis
The TERM.AMOUNT Property supports the following actions:
DECREASE
The Decrease activity is initiated manually and allows the User to decrease the commitment amount
of the arrangement subject to any negotiation rules, periodic rules, and the current outstanding
amount. This action is initiated as part of the DECREASE-TERM.AMOUNT ACTIVITY.

DRAW
The draw action is processed when a loan is disbursed. The action will:
• Validate that the amount to be disbursed is available.
• Raise the accounting event to reduce the available commitment amount.
• Update limits to reflect the reduced commitment amount if the commitment limit is updated.

INCREASE
The Increase activity is initiated manually and allows the User to increase the commitment amount of
the arrangement subject to any negotiation rules and periodic rules. This action is initiated as part of
the INCREASE-TERM.AMOUNT CLASS.

REPAY
The Repay activity is triggered from either a repayment transaction or as a result of a Payment Rule.
It runs the corresponding accounting rules and may update the available amount according to the
Revolving attribute condition.

UPDATE
The UPDATE action is initiated manually and allows the User to change any of the TERM.AMOUNT
attributes. This action will be initiated as part of the NEW-ARRANGEMENT and UPDATE-
TERM.AMOUNT activities.

CHANGE.TERM
The Change Term activity allows for a user to increase or decrease the Term of an arrangement
subject to the negotiation rules.

Other actions are CREDIT, DEBIT, MATURE, CAPITALISE and ACCT.CAPITALISE.

TEMENOS T24 User Guide Page 137 of 183

Arrangement Architecture – Introduction / Property Classes

Accounting Events
The following actions generate accounting events as defined in field ACCOUNTING.
• DECREASE
• DRAW
• INCREASE
• REPAY
• MATURE
• CAPITALSIE
• DEBIT
• CREDIT
• ACT.CAPITALSIE

Limits Interaction

The committed amount of the transaction will be updated in the LIMIT application.

Delivery
The ACTIVITY.MESSAGING property class controls the T24 delivery events that are generated.

TEMENOS T24 User Guide Page 138 of 183

Arrangement Architecture – Introduction / Property Classes

ACTIVITY.RESTRICTION
Overview
The ACTIVITY.RESTRICTION Property Class can be used to govern the types and amounts of
transactions on an Arrangement.

Product Lines
The ACTIVITY.RESTRICTION Property is used by the following product lines:

• LENDING
• DEPOSITS
• ACCOUNTS

Property Product Relationship

The ACTIVITY.RESTRICTION Product property supports the following arrangement links to the
product:

• CCY
• DATED
• MULTIPLE
• TRACKING

TEMENOS T24 User Guide Page 139 of 183

Arrangement Architecture – Introduction / Property Classes

ACTIVITY.RESTRICTION Property Class record.

Multiple instances of a property class

It is possible to have more than one instance of a ACTIVITY.RESTRICTION property class.

Defining the Activity Restrictions at Product Level

Transaction rules would be defined at Product level and are tracking so that any changes to a
condition are automatically applied to any arrangement using that product. The ACTIVITY.MAPPING

TEMENOS T24 User Guide Page 140 of 183

Arrangement Architecture – Introduction / Property Classes

Property Class will map transaction codes to Activities. The user can then specify any transaction
activities in ACTIVITY.ID which will have rules applied against them.

• Complete Restriction - T24 allows for the complete restriction of the specified transactions. A
user can flag the transactions to be restricted and can specify whether a transaction of this type
will result in an Error or an Override. The Error or Override message is user definable.
• Periodic Rules - T24 enables users to define transaction rules bases upon periods of time
(including the full lifetime of the arrangement). See next section.
If any of these transaction rules are broken, the User can select either an RESTRICT.OVR or
RESTRICT.ERROR to be generated by the system.

Periodic Attribute Classes associated with Activity Restriction

The ACTIVITY.RESTRICTION Property Class provides the following Periodic Attribute Classes from
which users may define Periodic Attributes.

Transaction Amount Maximum

The user can restrict the maximum AMOUNT allowed for the Activity for any single activity. The
amount of the activity is assumed as the TXN.AMOUNT in the AA.ARRANGEMENT.ACTIVITY
record for the current activity being processed.

TRANSACTION.AMOUNT.MAXIMUM record.

The PR.VALUE must specify the maximum AMOUNT allowed.

TEMENOS T24 User Guide Page 141 of 183

Arrangement Architecture – Introduction / Property Classes

Transaction Amount Minimum

The user can restrict the minimum AMOUNT allowed for the Activity for any single activity. The
amount of the activity is assumed as the TXN.AMOUNT in the AA.ARRANGEMENT.ACTIVITY
record for the current activity being processed.

TRANSACTION.AMOUNT.MINIMUM record.

The PR.VALUE must specify the minimum AMOUNT allowed.

Transaction Amount Total

The user can restrict the maximum TOTAL AMOUNT for an activity over a specified (defined in
AA.PERIODIC.ATTRIBUTE). For example the total amount to be disbursed over a 3 month period
would be restricted using this rule.
Processing will determine the total amount processed within the defined period to date and will
calculate and verify if the current activity request is within the specified maximum value. If it is not
either an error or override message will be generated.

The PR.VALUE must specify the maximum total AMOUNT for the activity allowed within a period.

TEMENOS T24 User Guide Page 142 of 183

Arrangement Architecture – Introduction / Property Classes

TRANSACTION.AMOUNT.TOTAL record.

Transaction Amount Multiple

The user can restrict the amount of an activity to be in multiples specified as the associated
PR.VALUE. For example if disbursal is only allowed in multiples of 5,000 a rule value of 5,000 should
be defined.
Processing will validate that the current activity amount is a multiple of the defined amount.

TRANSACTION.AMOUNT.MULTIPLE record.

TEMENOS T24 User Guide Page 143 of 183

Arrangement Architecture – Introduction / Property Classes

The PR.VALUE must specify the multiple AMOUNT of an activity allowed.

Transaction Count Total

The user can restrict the number of activity over a specified period. The Maximum number of
transactions allowed in a period is defined in the associated PR.VALUE.
Processing will determine the current count of activities of the current type requested in the
processing period and will validate that an additional activity is within the allowed number.

TRANSACTION.COUNT.TOTAL record.

The PR.VALUE must specify the maximum NUMBER of Activities allowed within a period.

TEMENOS T24 User Guide Page 144 of 183

Arrangement Architecture – Introduction / Property Classes

Curr Loan Repay Tolerance

The user can use this restriction to control repayment amounts by comparing the repaid amount as a
percentage of the available loan balance at the start of the restriction period.
The periodic attribute will be validated when a repayment is made against the loan.
The periodic rule will be linked to an activity of the LENDING-APPLYPAYMENT-PAYMENT.RULES
class.
The processing will take the current committed loan balance at the calculated period start, calculate
the percentage, and compare this with the total repayment in the period.

CURR.LOAN.REPAY.TOLERANCE record.

In the PR.VALUE you must specify the percentage amount to be calculated.

TEMENOS T24 User Guide Page 145 of 183

Arrangement Architecture – Introduction / Property Classes

Total Loan Repay Tolerance

This attribute class is similar to CURR.LOAN.REPAY.TOLERANCE but will provide a restriction to the
repaid amount as a percentage of the total committed loan balance at the start of a given period.
The periodic attribute will be validated when a repayment is made against the loan. The periodic rule
will be linked to an activity of the LENDING-APPLYPAYMENT-PAYMENT.RULES class.
The processing will take the total committed loan balance at the calculated period start calculate the
percentage, and compare this with the total repayment in the period.

TOTAL.LOAN.REPAY.TOLERANCE record.

In the PR.VALUE you must specify the percentage amount to be calculated.

An example of this restriction in practice can be seen below.

The following AA.PERIODIC.ATTRIBUTE record is created with the above class specified in the
field PR.ATTR.CLASS.
For this example the DURATION.TYPE is set to INITIAL which means the restriction applies for an
initial period only of an arrangements life time. A PERIOD of 1W has been entered which is the
restriction duration. The RULE.START field is set as START which means from arrangement
disbursement the rule will be initiated.

TEMENOS T24 User Guide Page 146 of 183

Arrangement Architecture – Introduction / Property Classes

AA.PERIODIC.ATTRIBUTE example.

The AA.PERIODIC.ATTRIBUTE record TOTAL.LOAN.REPAY.TOL.1W is then entered into the

AA.PRD.DES.ACTIVITY.RESTRICTION record in field PR.ATTRIBUTE as shown below.

AA.PRD.DES.ACTIVITY.RESTRICTION example.

A PR.VALUE of 20 is specified which is converted into a percentage based on the

AA.PERIODIC.ATTRIBUTE.CLASS field COMPARISON.TYPE and its value TOLERANCE.
A value of OVERRIDE is specified in PR.BRK.RES which means the OVERRIDE record
AA.DEFVALUE as specified in PR.BRK.MSG will be invoked if this restriction is met. Another option at
this stage is to specify an ERROR in field PR.BRK.RES which will prohibit the user processing the
repayment.

TEMENOS T24 User Guide Page 147 of 183

Arrangement Architecture – Introduction / Property Classes

The AA.APRD.DES.ACTIVITY.RESTRICTION record 20%.TOTAL.REPAY.WEEKLY-USD-

20001130 is then linked to the PRD.PROPERTY field in the AA.PRODUCT.DESIGNER record.

AA.PRODUCT.DESIGNER with record added.

After a Proof and Publish is performed in the AA.PRODUCT.MANAGER application the catalogued
Product can now be traded. An AA.ARRANGEMENT.ACTIVITY can be created as shown below.

AA.ARRANGEMENT.ACTIVITY record.

TEMENOS T24 User Guide Page 148 of 183

Arrangement Architecture – Introduction / Property Classes

As you can see on the commitment tab above a loan of $2,000 was given for a 1 month duration.
This commitment amount is then full disbursed with a FUNDS.TRANSFER as shown below.

FUNDS.TRANSFER disbursal amount USD 2,000.

With the above configuration established any repayment amount above the specified 20% which
equates to $400 (2,000 * 20%) will show the specified OVERRIDE.

The following FUNDS.TRANSFER is transacted to repay the arrangement, as you can see the
OVERRIDE to tolerance is shown.

TEMENOS T24 User Guide Page 149 of 183

Arrangement Architecture – Introduction / Property Classes

OVERRIDE showing a -20-05% tolerance.

To suite the users purpose the configuration of multiple AA.PERIODIC.ATTRIBUTE records and
the linking to the AA.PRD.DES.ACTIVITY.RESTRICTION records by association of multi-values
can be of a more complex nature if required.

TEMENOS T24 User Guide Page 150 of 183

Arrangement Architecture – Introduction / Property Classes

Action Synopsis
The ACTIVITY.RESTRICTION Property supports the following actions:
UPDATE
The UPDATE action is initiated manually and allows the User to change any of the
ACTIVITY.RESTRICTION attributes. This action will be initiated as part of the NEW-ARRANGEMENT and
UPDATE-ACTIVITY.RESTRICTION activities.

EVALUATE
The EVALUATE action is initiated automatically as part of any activity processed by the system. The
EVALUATE action will perform the following:

• Check to see if the current AA.ACTIVITY is restricted according to the

AA.ARR.ACTIVITY.RESTRICTION definition of the product. If there is a restriction an error or
override will be generated as specified in the RESTRICTION.TYPE field.

• If the current AA.ACTIVITY is not restricted then any PR.ATTRIBUTE linked to the
AA.ARR.ACTIVITY.RESTRICTION definition for the product will be evaluated in turn.
Processing within the AA.PERIODIC.ATTRIBUTE.CLASS may contain condition processing
based on product and activity – see Periodic Restriction section for further details.

Accounting Events
The ACTIVITY.RESTRICTION property does not perform any actions that generate accounting events.

Limits Interaction
The ACTIVITY.RESTRICTION property does not perform any actions that impact on the limits system.

Delivery
The ACTIVITY.MESSAGING property class controls the T24 delivery events that are generated. There
is no special delivery processing required for the ACTIVITY.RESTRICTION property.

TEMENOS T24 User Guide Page 151 of 183

Arrangement Architecture – Introduction / Property Classes

PAYOFF
Overview
The PAYOFF property class can be included in products where user wants to generate payoff
statement at the arrangement level. The payoff statement should include all Principal, Interest and
Charges that will be due as a result of the payoff.
The payoff calculation should produce a record with the itemised calculated amounts. It should be
possible to adjust the system calculated amounts and also should be possible to show the adjusted
amounts along with the original calculated amounts in payoff statement.
New periodic attribute classes have been introduced to throw error/override in case of under/over
payments.

Product Lines
The PAYOFF property is used only in LENDING product line.

Property Product Relationship

The PAYOFF property supports the following arrangement links to the product:

• DATED
• TRACKING

TEMENOS T24 User Guide Page 152 of 183

Arrangement Architecture – Introduction / Property Classes

PAYOFF Property Class record.

The PAYOFF property will have date as part of the designer condition ID and can be set to track the
product changes.

Related balances
The PAYOFF property does not have any related financial balances.

Property Attribute Description and Use

Defining the Expiry Days:
The user must enter the number of days after which the payoff bill will be invalidated. System would
update the cancel activity in scheduled activity on which the payoff bill will be invalidated.

Repayment Activity:
When the settlement is made against the payoff bill payment allocation is made based on the apply
payment activity defined in this field. This field is mandatory at the arrangement level. User can make
settlement against payoff bill on any day between the payoff date and expiry date.

Auto Repay:

TEMENOS T24 User Guide Page 153 of 183

Arrangement Architecture – Introduction / Property Classes

The payoff bill is generated through the activity LENDING-CALCULATE-PAYOFF. If the payoff date is
on a forward date a decision can be made whether the future scheduled payments should be
considered to be settled (This assumes the all the future payments will be settled by the user and
future payments will not be updated in payoff bill).
If the field SETTLE.DUES is set to YES then system settles the future scheduled payments
automatically (Related activity). The repayment activity to be used should be given in field
SETTLE.DUE.ACT.
If it set to NO in payoff bill all the future payments will be shown against the overdue due.

Payoff designer condition:

AA.ARR.PAYOFF record by arrangement.

Generating payoff bill

Payoff bill is generated either via the application AA.SIMULATION.CAPTURE or
AA.ARRANGEMENT.ACTIVITY.
Payoff bill creation using simulation capture:
Steps in involved in creating payoff via simulation capture.
1. Input simulation capture for an arrangement with activity set to LENDING-CALCULATE-PAYOFF.
2. Field EFFECTIVE.DATE indicates whether payoff date is forward or today
3. On authorising the simulation capture system would trigger the activity LENDING-ISSUE-PAYOFF
and creates a record in AA.SIMULATION.RUNNER. Simulation runner would have the list of
activities to be triggered from today to payoff. Authorising the simulation capture and running the
service AA.SIMULATION.SERVICE system would update the $SIM files.
4. Now when the user commit and authorise the simulation runner with flag EXECUTE.SIMULATION
set to YES and running the service AA.SIMULATION.SERVICE system writes the payoff bill in live
files.

TEMENOS T24 User Guide Page 154 of 183

Arrangement Architecture – Introduction / Property Classes

AA.SIMULATION.CAPTURE arrangement record.

AA.ARR.PAYOFF arrangement record.

The above shown simulation capture was input on 4th Dec 2000 with payoff date set to 29th Dec 2000
(Forward dated payoff). From the payoff designer record it can be seen that system would settle any
scheduled payments between capture date and payoff date.
Expiry days is set to NULL and it means that if the settlement does not happen on 29th Dec 2000
system would invalidate the payoff bill on the same day close of business.
Simulation runner record:

TEMENOS T24 User Guide Page 155 of 183

Arrangement Architecture – Introduction / Property Classes

AA.SIMULATION.RUNNER record.

In the above scenario between capture and payoff there is only one scheduled payment (on 15th Dec
2000). Since SETTLE.DUES is set to YES system triggers the repayment activity automatically.

Payoff Bill:
From the payoff bill it can seen that there is no overdue details displayed.
If the expiry is not null say it is set to 1. Payoff bill will be invalidated after one working day. For
example say the payoff date is 29th Dec 2000 and expiry date is 1st Jan 2001 (After 29th Dec 2000
next working day is 1st Jan 2001) system would update per diem for 30th Dec 2000, 31st Dec 2000 and
1st Jan 2001 in payoff bill.

TEMENOS T24 User Guide Page 156 of 183

Arrangement Architecture – Introduction / Property Classes

AA.BILL.DETAILS record.

Payoff bill creation via arrangement activity:

The user can generate the payoff bill online as well. For example a payoff bill generated by the
system as shown in the previous case.
Now a user changes the property amounts using the activity LENDING-ADJUST.INFO.BILL-
BALANCE.MAINTENANCE so that the payoff bill is updated with the adjusted amounts. The user can
trigger the activity LENDING-ISSUE-PAYOFF manually so that delivery messages can be triggered with
new payoff bill details.

TEMENOS T24 User Guide Page 157 of 183

Arrangement Architecture – Introduction / Property Classes

Periodic attribute classes associated with Pay off

The PAYOFF Property class provides the following periodic attribute class from which users may
define periodic attributes

Payoff Neg Difference

During payoff bill settlement when the repayment amount is greater than the payoff bill amount this
periodic attribute class can be used such that system would throw an error message.

PAYOFF.NEG.DIFFERENCE record.

Payoff Pos Difference

During payoff bill settlement when the repayment amount is less than the payoff bill amount this
periodic attribute class can be used such that system generates override messages.

TEMENOS T24 User Guide Page 158 of 183

Arrangement Architecture – Introduction / Property Classes

PAYOFF.POS.DIFFERENCE record.

Activity class related to payoff property class

The following activity class records has been introduced in addition to this payoff property class
LENDING-CALCULATE-PAYOFF
This activity can only be triggered via simulation mode and it is not user triggered activity. When
triggered in simulation mode system builds simulation runner record with the list of activities to be
executed. This activity cannot be reversed.
LENDING-CANCEL-PAYOFF
This activity can be either triggered online or scheduled on the expiry date. It is used to delete the
payoff bill from bill details and account details. This activity cannot be reversed.
LENDING-CHANGE.CONDITION-PAYOFF
This activity can be used when the payoff designer condition to be changed at the product level.
These condition changes will not any impact on the existing unless the ARR.LINK is set to
TRACKING
LENDING-ADJUST.INFO.BILL-BALANCE.MAINTENANCE
This activity can be used to change the property amounts in the payoff bill. This activity updates only
the payoff bill.
LENDING-ISSUE-PAYOFF
This activity can be used if any adjustment made to payoff bill using the adjust info activity. This can
be triggered online so that delivery messages to be generated with the adjusted amount (Payoff bill).

LENDING-SETTLE-PAYOFF:
Using this activity user can make payment against the payoff bill. System uses the repayment activity
in payoff designer record for payment allocation.
LENDING-UPDATE-PAYOFF:

TEMENOS T24 User Guide Page 159 of 183

Arrangement Architecture – Introduction / Property Classes

This activity can be used to change the payoff designer condition either at the arrangement level or at
the product level.

Action synopsis
The PAYOFF Property supports the following actions:
CALCULATE
This action routines builds payoff bill details record with the following details
• Current balances to be settled
• Overdue balances
• Due balances
• Per diem interest
• Charges if any
• System writes the payoff bill in $SIM files

CANCEL
This action deletes the payoff bill reference from AA.BILL.DETAILS and
routine
AA.ACCOUNT.DETAILS. This can be triggered as a scheduled activity or user defined activity

ISSUE
This action routine reads the payoff bill from $SIM file and writes it in live file

SETTLE
This action routine is triggered when the customer makes payments against the payoff bill.

UPDATE
This action routine is triggered when the user amends the payoff designer using update activity.

Accounting Events
This action routine of this property class does not generate any accounting entries. The existing
repayment functionality applies.

Delivery
The delivery processing has been modified to add the payoff bill detail in handoff record. Now a hard
codes file name AA.PAYOFF.BILL.DETAILS updated in handoff record.

TEMENOS T24 User Guide Page 160 of 183

Arrangement Architecture – Introduction / Property Classes

SETTLEMENT
Overview
The SETTLEMENT property class can be used when bills issued are to be settled directly by debiting
an account in a third party bank. This is achieved by linking a mandate defined in the Direct Debit
(DD) module to an arrangement account which is done through this SETTLEMENT Property.
For the direct debit to work, the mandate should have a status of ACTIVE/AVAILABLE. When bills are
issued, DD.ITEM records will be created by the system for the payment types that are specified in
the SETTLEMENT property. On the claim date (the value date of the bill payment), the arrangement
account is credited with funds and appropriated according the rules specified in PAYMENT.RULES
property.
When a claim is generated if the transaction code in DD.TXN.CODES for CLAIMED ITEM CREDIT
is mapped to an activity via ACTIVITY.MAPPING, the corresponding activity will be run. This will settle
the bills that are made due and will update the necessary files.
When a claimed item is returned then the repayment activity will have to be reversed and the
corresponding files will have to be reinstated to its initial status.

Product Lines
The SETTLEMENT property is used by the following product line:

• LENDING

Product Property Relationship

The SETTLEMENT product property supports the following arrangement links to the product:

• CCY
• DATED

TEMENOS T24 User Guide Page 161 of 183

Arrangement Architecture – Introduction / Property Classes

SETTLEMENT Property Class record.

Property Attribute Description and Uses

For the claim to credit arrangement account and to settle the proceeds of the bills that are made due,
the credit transaction code of DD claimed item should be linked to a repayment activity in AA.

DD.TXN.CODES for different transactions of DD.

TEMENOS T24 User Guide Page 162 of 183

Arrangement Architecture – Introduction / Property Classes

The DD.TXN code for CLAIMED.ITEM is to be linked with a repayment rule as shown below:

Activity mapping with repayment activity mapped.

The following additional steps are required:

The payment rule which has been created specifically for the direct debit should have the activity
LENDING-CREDIT-ARRANGEMENT in the field REMAINDER.ACTIVITY, such that when the claim is
actually processed, the credit will first be made by the DD module to the unallocated balance of the
arrangement account. This should have only the properties of the payment types defined in
SETTLEMENT property condition of the arrangement. It should not have any additional properties:

Rule on how bills are to be settled.

As shown below, the APPLY.PAYMENT field in the payment schedule property should be input with
the payment rule for the direct debit. This will result in the AA module appropriating the unallocated
balance to the properties specified for settlement.

TEMENOS T24 User Guide Page 163 of 183

Arrangement Architecture – Introduction / Property Classes

APPLY.PAYMENT field with repayrule1.

Linking DD with Arrangement

After the new arrangement input, the account number of the arrangement is used to create a
DD.DDI record (mandate) to provide a link to the arrangement.

Arrangement with account number updated.

DD.DDI record for the arrangement account.

TEMENOS T24 User Guide Page 164 of 183

Arrangement Architecture – Introduction / Property Classes

The DD.DDI record status should be AVAILABLE to make use of the direct debit functionality to
settle the bills. In the first instance, when the DD.DDI record is created the status will be NEW and
after authorisation, the same should be changed to AVAILABLE.
The mandate created through DD.DDI should be updated in the field DD.MANDATE.REF in the
SETTLEMENT property condition of the arrangement using LENDING-UPDATE-SETTLEMENT activity.
The field PAYMENT.TYPE can hold any of the payment types defined in payment schedule. The field
SETTLE.METHOD should be DD.

SETTLEMENT condition at arrangement level.

During bill issuance, records in DD.ITEM will be created for every payment type defined in
SETTLEMENT property with the contract reference as the AA.ARRANGEMENT.ACTIVITY ID of the
issue-bill activity.

Processing of the DD linked to AA

In the example below, the bill is issued 2 days prior to the due date i.e. the due date is on 15th Dec
and the bill is issued on 30th Nov during end of day process (The working days being 30th Nov, 4th
Dec, 15th Dec....)

TEMENOS T24 User Guide Page 165 of 183

Arrangement Architecture – Introduction / Property Classes

Payment schedule definition with bills issued 2 days prior to due date.

The issue bill activity triggers creation of DD.ITEM records for the payment types that are mentioned
in the SETTLEMENT property.

DD.ITEM with status as NEW.ITEM

TEMENOS T24 User Guide Page 166 of 183

Arrangement Architecture – Introduction / Property Classes

The status of the DD.DDI record will be NEW.ITEM till the payment is processed. And the contract
reference updated is the respective issue-bill activities for the arrangement for different payment
types. Bill is in ISSUED status:

AA.BILL.DETAILS with bill status as ISSUED

The figure below shows that the status of the bill has been updated after the DD processing on the
payment date of the bill. The DD.ITEM record has status updated to CLAIMED.ITEM.

TEMENOS T24 User Guide Page 167 of 183

Arrangement Architecture – Introduction / Property Classes

Bill settled.

DD.ITEM updated as CLAIMED.ITEM.

TEMENOS T24 User Guide Page 168 of 183

Arrangement Architecture – Introduction / Property Classes

Balance movements:

Movements shown on how DUE balances are settled via UNC balance.

Synopsis of Actions
The SETTLEMENT Property supports the following actions:
CREATE.DD
This action is triggered when the DD.ITEM is created during ISSUE-BILL activity.

UPDATE
This action is initiated manually and allows the user to change any of the SETTLEMENT attributes.

TEMENOS T24 User Guide Page 169 of 183

Arrangement Architecture – Introduction / Property Classes

PROTECTION.LIMIT
Overview
The PROTECTION LIMIT Property Class is used by products which have daily limits on the cumulative
amount of transactions that can be done via an external channel (e.g. Internet, Mobile, ATM, etc.).
These limits can be applied at the Customer and/or External User levels1. The aim of this functionality
is to reduce the amount of money that can be fraudulently obtained by bad guys who have
compromised the system (e.g. by stealing user credentials, ‘man in the middle’ attacks, or an insider
with system access) while minimising the inconvenience to legitimate users. It can also impose limits
on internal transactions such as account to account transfers.
Products which utilize this class can have multiple PROTECTION LIMIT Properties defined.

Product Lines
The PROTECTION.LIMIT property is used by the following product lines:

• INTERNET SERVICES

Property Product Relationship

The PROTECTION.LIMIT product property supports the following arrangement links to the product:

• DATED
• MULTIPLE
• TRACKING

PROTECTION.LIMIT Property Class record.

TEMENOS T24 User Guide Page 170 of 183

Arrangement Architecture – Introduction / Property Classes

Defining Limits against certain Transactions

By default a limit which is established applies to all transactions. Should a user wish to limit certain
transactions whilst leaving others unrestricted they can do so by limiting the transactions. The product
code (e.g. FT, SC, etc) is input into field SYSTEM.ID. Additionally, the actual application (e.g.
FUNDS.TRANSFER, STANDING.ORDERS, etc.) is input into field APPLICATION.
The Limit can be limited further by selecting a TRANS.TYPE. This field is linked to
EB.TRANSACTION.TYPE which is used to group multiple transaction codes together. Field
ALLOWED.CCY limits the currency within the defined application and transaction.
Field BEN.RISK.RATE defines the risk rating that is assigned to the beneficiary.
These options are each multi-valued and aggregated with each other. For example should a user
choose an ‘Application’ of FUNDS.TRANSFER and a ‘Beneficiary Risk’ of High, then only
transactions initiated via FUNDS.TRANSFER, to a high-risk beneficiary will have the limit applied.

The user specifies the LIMIT.AMOUNT in a specific CURRENCY (e.g. USD 2000).

Action Synopsis
The PROTECTION.LIMIT Property supports the following actions:
UPDATE
The update action is initiated manually and allows the User to change any of the PROTECTION.LIMIT
attributes. This action will be initiated as part of the NEW-ARRANGEMENT and UPDATE-
PROTECTION.LIMIT activities.

Accounting Events
The PROTECTION.LIMIT property does not perform any actions that generate accounting events.

Limits Interaction
The PROTECTION.LIMIT property does not perform any actions that impact on the limits system.

Delivery
The ACTIVITY.MESSAGING property class controls the T24 delivery events that are generated.

Please see the ARC-IB Administration User guide for full set-up with External User.

TEMENOS T24 User Guide Page 171 of 183

Arrangement Architecture – Introduction / Property Classes

UI.APPEARANCE
Overview
The UI.APPEARANCE Property Class defines the User appearance properties. It can be used to
configure tool style, language, skin, date format and amount format at the design level.
These field values will override the EB.EXTERNAL.USER and BROWSER.PREFERENCES
settings during runtime.

Product Lines
The UI.APPEARANCE property is used by the following product lines:

• INTERNET SERVICES

Property Product Relationship

The UI.APPEARANCE product property supports the following arrangement links to the product:

• DATED
• TRACKING

UP.APPEARNCE Property Class record.

TEMENOS T24 User Guide Page 172 of 183

Arrangement Architecture – Introduction / Property Classes

Action Synopsis
The UI.APPEARANCE Property supports the following actions:
UPDATE

Accounting Events
The UI.APPEARANCE property does not perform any actions that generate accounting events.

Limits Interaction
The UI.APPEARANCE property does not perform any actions that impact on the limits system.

Delivery
The ACTIVITY.MESSAGING property class controls the T24 delivery

Please see the ARC-IB Administration User guide for full set-up with External User.

TEMENOS T24 User Guide Page 173 of 183

Arrangement Architecture – Introduction / Property Classes

UI.BEHAVIOUR
Overview
The UI.BEHAVIOUR Property Class defines the manner in which external users can interact with the
internet bank application.

Product Lines
The UI.BEHAVIOR property is used by the following product lines:

• INTERNET SERVICES

Property Product Relationship

The UI.BEHAVIOR product property supports the following arrangement links to the product:

• DATED
• TRACKING

UI.BEHAVIOUR Property Class record.

TEMENOS T24 User Guide Page 174 of 183

Arrangement Architecture – Introduction / Property Classes

Action Synopsis
The UI.BEHAVIOR Property supports the following actions:
UPDATE

Accounting Events
The UI.BEHAVIOR property does not perform any actions that generate accounting events.

Limits Interaction
The UI.BEHAVIOR property does not perform any actions that impact on the limits system.

Delivery
The ACTIVITY.MESSAGING property class controls the T24 delivery

Please see the ARC-IB Administration User guide for full set-up with External User.

TEMENOS T24 User Guide Page 175 of 183

Arrangement Architecture – Introduction / Property Classes

USER.RIGHTS
Overview
The USER.RIGHTS Property Class is used by products to set the conditions on which an external user
can do, view and when they are allowed to access the system.

Product Lines
The USER.RIGHTS property is used by the following product lines:

• INTERNET SERVICES

Property Product Relationship

The USER.RIGHTS product property supports the following arrangement links to the product:

• DATED
• TRACKING

USER.RIGHTS Property Class record.

TEMENOS T24 User Guide Page 176 of 183

Arrangement Architecture – Introduction / Property Classes

Action Synopsis
The USER.RIGHTS Property supports the following actions:
UPDATE

Accounting Events
The USER.RIGHTS property does not perform any actions that generate accounting events.

Limits Interaction
The USER.RIGHTS property does not perform any actions that impact on the limits system.

Delivery
The ACTIVITY.MESSAGING property class controls the T24 delivery

Please see the ARC-IB Administration User guide for full set-up with External User.

TEMENOS T24 User Guide Page 177 of 183

Arrangement Architecture – Introduction / Property Classes

PROXY.PERMISSIONS
Overview
The PROXY.PERMISSIONS Property Class defines the manner in which external users can interact
with the internet bank application.

Product Lines
The PROXY.PERMISSIONS property is used by the following product lines:

• INTERNET SERVICES

Property Product Relationship

The PROXY.PERMISSIONS product property supports the following arrangement links to the product:

• DATED
• NON.TRACKING

PROXY.PERMISSIONS Property Class record.

TEMENOS T24 User Guide Page 178 of 183

Arrangement Architecture – Introduction / Property Classes

Action Synopsis
The PROXY.PERMISSIONS Property supports the following actions:
UPDATE

Accounting Events
The PROXY.PERMISSIONS property does not perform any actions that generate accounting events.

Limits Interaction
The PROXY.PERMISSIONS property does not perform any actions that impact on the limits system.

Delivery
The ACTIVITY.MESSAGING property class controls the T24 delivery

Please see the ARC-IB Administration User guide for full set-up with External User.

TEMENOS T24 User Guide Page 179 of 183

Arrangement Architecture – Introduction / Property Classes

PRODUCT.ACCESS
Overview
The PRODUCT.ACCESS Property Class defines the manner in which external users can interact with
the internet bank application.

Product Lines
The PRODUCT.ACCESS property is used by the following product lines:

• INTERNET SERVICES

Property Product Relationship

The PRODUCT.ACCESS product property supports the following arrangement links to the product:

• DATED
• TRACKING

PRODUCT.ACCESS Property Class record.

TEMENOS T24 User Guide Page 180 of 183

Arrangement Architecture – Introduction / Property Classes

Action Synopsis
The PRODUCT.ACCESS Property supports the following actions:
UPDATE

Accounting Events
The PRODUCT.ACCESS property does not perform any actions that generate accounting events.

Limits Interaction
The PRODUCT.ACCESS property does not perform any actions that impact on the limits system.

Delivery
The ACTIVITY.MESSAGING property class controls the T24 delivery

Please see the ARC-IB Administration User guide for full set-up with External User.

TEMENOS T24 User Guide Page 181 of 183

Arrangement Architecture – Introduction / Property Classes

ARRANGEMENT.PREFERENCES
Overview
The ARRANGEMENT.PREFERENCES Property Class defines the manner in which external users can
interact with the internet bank application.

Product Lines
The ARRANGEMENT.PREFERENCES property is used by the following product lines:

• INTERNET SERVICES

Property Product Relationship

The ARRANGEMENT.PREFERENCES product property supports the following arrangement links to the
product:

• DATED

ARRANGEMENT.PREFERENCES Property Class record.

TEMENOS T24 User Guide Page 182 of 183

Arrangement Architecture – Introduction / Property Classes

Action Synopsis
The ARRANGEMENT.PREFERENCES Property supports the following actions:
UPDATE

Accounting Events
The ARRANGEMENT.PREFERENCE property does not perform any actions that generate accounting
events.

Limits Interaction
The ARRANGEMENT.PREFERENCE property does not perform any actions that impact on the limits
system.

Delivery
The ACTIVITY.MESSAGING property class controls the T24 delivery.

Please see the ARC-IB Administration User guide for full set-up with External User.

TEMENOS T24 User Guide Page 183 of 183